Object Oriented Programming - i jego pułapki. Opcje

[LoPMX]

Tak wlasnie siedze i mysle sobie, bo chce przepisac swoja aplikacje z GOD classes na prawdziwe OOP. Chce aby kazda klasa reprezentowala jeden typ danych, np. klasa Articles ma metody tworzace obiekty klasy Article, ktora posiada z kolei metody zwracajace dane danego artykulu. Ale jest problem... Artykuly w bazie danych polaczone sa relacyjnie z Article_Type, oraz Category. I problem w tym, ze klasa Article_Type to tylko article_type z DB, Category to tylko category z DB. W templejcie potrzebuje wyswietlic artykuly wraz z ich kategoria oraz typem (np. test, recenzja czy cokolwiek innego). I nie wiem, jak mam polaczyc te obiekty. Moge oczywiscie zrobic wywolanie obiektu Category z Article, ale to za kazdym wyswietleniem danych tworzy jedno zapytanie do bazy o nazwe kategorii. Ma ktos jakis pomysl?

[bumelang]

php ma chyba za dużą narośl kompatybilności, żeby udało się to wprowadzić z powodzeniem. [...]

W naszym systemie A1 Framework każda strona to własnie taka klasa. Oczywiście owa klasa nie działa tak sama z siebie (choć na dobrą sprawę można byłoby coś takiego osiągnąć, używając na przykład auto_prepend i auto_append - vide http://www.zend.com/zend/spotlight/prepend.php). [...]

Szczerze podziwiam, ale nie widzę związku. Komentowałem to, co mój poprzednik napisał o wielowątkowości php, a mój przykład z klasą rozszerzającą obiekt Page, tyczył się raczej kierunku w którym idzie język (a raczej w którym nie idzie) i nie należy go traktować dosłownie - raczej jako nawiązanie do .NET i Javy.

Reausumując - doceniam rolę obiektów w tworzeniu pluginów i różnego rodzaju systemów o architekturze komponentowej, ale dalej obstaję, że typowy (i to wcale nie zgorszy) projekt php to Smarty + AdoDB + proceduralny kod, a wszelkie modelowania O/R to już czysta fanaberia.

Muszę tutaj polemizować, bowiem jakiś czas temu stworzyłem całkiem spory serwis właśnie w opisany przez Ciebie sposób [...] jeśli chodzi o kwestię rozwijania kodu, jego testowania, optymalizacji, modularyzacji, przestrzeni nazw, itd, to jest to prawdziwa mordęga. Dobrze zaprojektowany, obiektowy framework to dużo lepsze rozwiązanie.

I wcale tego nie negowałem, tylko że chyba nie do końca zrozumiałeś o czym mówię. Otóż najczęściej spotykane strony php są proste i w tym sensie warto mieć zestaw klas o charakterze bibliotek, ktore potem wykonują za nas czarną robotę związaną z typowymi zadaniami - jakieś walidacje, czy wyświetlanie nagłówka - to myślę nie ulega wątpliwości. Jeśli jednak tworzymy na stronie kilka formularzy i autoryzację, to kwestia czy nie jest przerostem formy nad treścią używanie jakiegoś frameworka w stylu, o jakim piszesz jest cokolwiek dyskusyjna, ale dla dużych to może być bardzo dobre rozwiązanie.

Ale to też nie była kwintesencja mojej wypowiedzi. Chodziło mi o bardziej ogólne zagadnienie, jakim jest całkowita obiektowość w stylu Javy, kiedy Twój program to w 100% klasy nie w sensie formalnym, ale logicznym - kiedy klasy nie stanowią zbioru funkcji, ale modelują rzeczywiste odwzorowania, jak np. wyciąganie artykułu ze źródła danych -> ubieranie go w klasę artykuł -> przekazywanie tej klasy do wyświetlacza. To moim zdaniem przynosi same problemy i żadnych korzyści - z powodów synchronizacji, wydajności, etc. A od tego właśnie zaczął się ten wątek.