Kilka pytań o praktyczne zastosowanie programowania obiektowego Opcje

[Zagiewa]

Witam. Dopiero wchodzę w programowanie obiektowe i choć oczytałem się już trochę, wiele poradników dostępnych w internecie opisuje obiektowość w sposób teoretyczny nie pokazując jak można go wykorzystać w praktyce dlatego też mam parę pytań, które nie dają mi spokoju.

1. Tworząc klasy powinno się je trzymać w tym samym pliku co całość kodu czy najlepiej jest utworzyć nowy plik zawierający tylko klasy, a następnie je includować w plikach w których będziemy z tych klas korzystać?
2. Jeśli utworzymy klasę to tworzenie do niej obiektów za pomocą np. formularzy jest proste (przynajmniej teoretycznie) natomiast jak zapisywać obiekty do bazy danych? zapisujemy samą nazwę obiektu czy należy zapisać nazwę wraz ze wszystkimi właściwościami tego obiektu? Np. mamy klasę o nazwie prostokąt. Właściwościami będzie bok_a i bok_b. Tworzymy nowy obiekt o nazwie pierwszy_prostokat i nadajemy mu właściwości bok_a=5 i bok_b=10 jak powinien wyglądać rekord gdy zapiszemy ten obiekt do bazy? bo mi przychodzą do głowy taki zapis:

id. || nazwa || bok_a || bok_b
1 || pierwszy_prostokat || 5 || 10

3. Czy nawet w przypadku prostych skryptów warto używać obiektowości? Dajmy na to tworząc księgę gości to ilość kodu niezależnie czy użyjemy kodu strukturalnego czy obiektowego jest niemal taka sama. Jeśli chodzi o czytelność jest też podobnie bo skrypt ogólnie jest prosty. Sposób zapisywania do bazy jest identyczny zmienia się co najwyżej struktura tabeli. Więc nasuwa się pytanie - jak pisać?

[Crozin]

@Darko:

Fail #1: Model MVC w skrócie: wywołanie Kontrolera -> Kontroler określa, że potrzeba użyć tego Widoku i wrzucić mu ten a ten Model(e) -> odpalenie Widoku. Jak widzisz Kontroler nie pośredniczy w przekazywaniu danych do Widoku - on sam potrafi sobie pobrać co mu jest potrzebne.
Fail #2: Ta myśl o tym, że powinna być tylko jedna instancja obiektu obsługującego bazę danych. No to prosta sytuacja, mamy następujące modele:

• Aktualności - pobiera aktualności do witryny z naszej lokalnej bazy danych
• Galeria - pobiera obrazy z naszej lokalnej bazy danych
• Użytkownik - j/w
• Użytkownik::zasugerujListęZnajomych - metoda wykorzystuje Facebookowe API i próbuje zwrócić nam sugerowaną listę znajomych danego użytkownika
• Płatności - nasza aplikacja to np. sklep internetowy z jednym z backendów w postaci aplikacji desktopowej, która operuje na bazie SQLite po czym udostępnia tą bazę na serwerze - tutaj Twoja teza zawodzi po raz pierwszy
• Magazyn - skoro to sklep, to musimy mieć jakiś magazyn - ale ten znajduje się daleko od nas i musimy się połączyć z jego bazą danych - tutaj Twoja teza zawodzi kolejny raz

To, że w zdecydowanej większości przypadków mamy dokładnie jedną instancję obiektu reprezentującego bazę danych (używanego przez różne Modele) nie oznacza, że tak będzie zawsze. Aplikacji korzystających z dwóch lub więcej baz danych na raz, jako tych lokalnych jest względnie niewiele, ale ot system umożliwiający założenie sobie forum czy bloga (który jest w osobnej bazie) - i już masz konieczność wykorzystania obu baz na niektórych podstronach.

Najlepiej podejrzyj jakieś rozwiązania frameworkowe Kohana

Jeżeli zależy Ci na tym by nauczyć się OOP - w kod Kohany v3 nawet nie zaglądaj (musisz się najpierw uodpornić (IMG:style_emoticons/default/biggrin.gif) ).

Ten post edytował Crozin 29.07.2010, 13:08:09

[darko]

@Darko:

Fail #1: Model MVC w skrócie: wywołanie Kontrolera -> Kontroler określa, że potrzeba użyć tego Widoku i wrzucić mu ten a ten Model(e) -> odpalenie Widoku. Jak widzisz Kontroler nie pośredniczy w przekazywaniu danych do Widoku - on sam potrafi sobie pobrać co mu jest potrzebne.

Taaaak, w idealnej implementacji, która nie istnieje powinien zostać zaimplementowany wzorzec obserwator i widoki powinny się same uaktualniać przy zmianie danych. To wiemy. Niestety praktyka, zwłaszcza frameworkowa oraz specyfika protokołu HTTP uniemożliwiają taką "najbliższą ideałowi" (którego nie ma!) implementację mvc i nie ma co udawać, że jest inaczej (IMG:style_emoticons/default/biggrin.gif) Oczywiście, że sam kontroler fizycznie nie przekazuje danych z modelu do widoku, jednak to w nim deklarujemy tę operację:
przykład a'la ZF:
// kontroler
public function xyzAction()
{
// przekazanie danych do widoku (w kontrolerze z modelu sic!)
$this->view->sth = $this->MyModel->getSth();
}
// (...)

// widok:
// xyz.phtml
<!-- (...) -->
<?php
if($this->sth):
foreach($this->sth as $test):
echo $test->x . '<br/>' . $test->y . '<br/>' . $test->z;
endforeach;
endif;
?>

Fail #2: Ta myśl o tym, że powinna być tylko jedna instancja obiektu obsługującego bazę danych. No to prosta sytuacja, mamy następujące modele:

• Aktualności - pobiera aktualności do witryny z naszej lokalnej bazy danych
• Galeria - pobiera obrazy z naszej lokalnej bazy danych
• Użytkownik - j/w
• Użytkownik::zasugerujListęZnajomych - metoda wykorzystuje Facebookowe API i próbuje zwrócić nam sugerowaną listę znajomych danego użytkownika
• Płatności - nasza aplikacja to np. sklep internetowy z jednym z backendów w postaci aplikacji desktopowej, która operuje na bazie SQLite po czym udostępnia tą bazę na serwerze - tutaj Twoja teza zawodzi po raz pierwszy
• Magazyn - skoro to sklep, to musimy mieć jakiś magazyn - ale ten znajduje się daleko od nas i musimy się połączyć z jego bazą danych - tutaj Twoja teza zawodzi kolejny raz

To, że w zdecydowanej większości przypadków mamy dokładnie jedną instancję obiektu reprezentującego bazę danych (używanego przez różne Modele) nie oznacza, że tak będzie zawsze. Aplikacji korzystających z dwóch lub więcej baz danych na raz, jako tych lokalnych jest względnie niewiele, ale ot system umożliwiający założenie sobie forum czy bloga (który jest w osobnej bazie) - i już masz konieczność wykorzystania obu baz na niektórych podstronach.

Jeżeli zależy Ci na tym by nauczyć się OOP - w kod Kohany v3 nawet nie zaglądaj (musisz się najpierw uodpornić (IMG:style_emoticons/default/biggrin.gif) ).

Albo ja czegoś nie rozumiem, albo Ty. Nie napisałem nigdzie, że zawsze musi być jedna instancja bazy danych i uparcie będę twierdził, że - nawet jeśli zdefiniujemy różne dane konfiguracyjne - to i tak powinniśmy mieć możliwość - przy zastosowaniu jednej instancji obiektu bazy danych - "przełączania się" pomiędzy bazami (patrz np. Zend_Application_Resource_Multidb). Tylko dlaczego mieszać kwestię komunikacji z zewnętrznym źródłem danych poprzez wspomniane FB API z modelem DB? Przecież w jakimś innym modelu obsłużysz sobie bez problemu dane z facebooka, z bazą danych nie ma to nic wspólnego, dopóki nie będziesz musiał na tych danych operować, gromadzić je w swojej bazie danych, ale i tu rozwiązanie jest proste - napisanie/użycie odpowiedniego modelu korzystającego z FB API i pobierającego dane. Oczywiście możesz napisać sobie własny pseudo-adapter, w którym będziesz symulować implementację np. metody pobierającej dane - select() gdzie zaimplementujesz pobieranie danych z FB. Grunt, to dostosować się do interfejsu. Dążę do tego, że w przypadku, kiedy mamy wiele źródeł z których pochodzą dane, możemy - trzymając się nadal koncepcji jednej instancji DB - implementować własne adaptery i przełączać się pomiędzy nimi, korzystając z jednolitego interfejsu. W ten sposób mamy możliwość rozróżniania źródła pochodzenia danych. Myślę, że jest to wykonalne.

// edit
można też wykorzystać factory do dynamicznego tworzenia obiektów DB dla poszczególnych źródeł pochodzenia danych.

Ten post edytował darko 29.07.2010, 14:24:55