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?

[DeyV]

Ok, peace (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) Rzeczywiście - "trochę" sie uniosłem...

Co prawda nadal uważam, że zmiany które pojawiły się w php5 były bardzo potrzebne, i że baaaardzo ułatwiły programowanie, szczególnie bardziej złożonych projektów. Z tego powodu nie przeszkadza mi to, że zaczerpnięte jest to z Javy. W końcu dobre pomysły warto zapożyczać. (o ile jeszcze nie są opatentowane (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) )
Choć przyznam szczerze, że nie zawsze tak uważałem.
Swojego czasu miałem bardzo dużo wątpliwości co do sensowności wprowadzenia np. ograniczania dostępności atrybutów w obiektach, do php. Po co pisać private, jeśli i tak każdy może (z uwagi na to, że bibliotka nie jest kompilowana) dowolnie ją zmodyfikować, i ingerować w to co tylko ma ochotę. A z drugiej strony - jeśli chciałem by jakaś metoda czy atrybut był "prywatny" to przecież wystarczyło dodać odpowiedni komentarz.
Jednak wraz z rozpoczęciem pracy nad kilkoma większymi projektami pisanymi konkretnie pod php5 szybko zmieniłem te zdanie.
W końcu bardzo ułatwiło to debugowanie skryptów. Wczesniej nie miałem możłiwości prostego sprawdzenia, czy którakolwiek z klas przez przypadek nie korzysta czasem z danego atrybutu. Jasne - można ograniczyć się tylko do udostępniania interfejsu zbudowanego z meod, ale nawet wtedy, przy wieloktrotnym dziedziczeniu - łatwo stracić kontorlę nad tym, gdzie co jest wykorzystywane.
I wtedy przekonałem się, że wystarczy dodać banalne słowo private, i odpalić serię testów (tak - XP też jest niezatąpione (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ) by wykryć wszelkie konfliktowe miejsca.
O ile to podnosi szybkość pisania i jego bezpieczeństwo - chyba niekogo nie trzeba przekonywać.
Podobnie jest z innymi nowościami. static umożliwiło w końcu zrezygnowanie z używania globali. Kod automatycznie stał się bardziej przejżysty.
Przesyłanie obiektów zawsze przez referencję - o ile wygodniejsze stało się pisanie.
Możliwość kontrolowania typu przesyłanego przez parametr obiektu (bez bagażu problemów płynących z wymuszonego rzutowania typów).
To wszystko są zmiany, które, przynajmniej jak dla mnie, czynią pisanie w php znacznie bardziej intuicyjne i sprawne.
Pozwoio mi to na porwanie się na projekty, których wcześniej nie podjąłbym się raczej w tym języku, w wersji 4. (Nie należę bowiem do ludzi, którzy potrafią kompilować programy na kartce, i wykrywać wszystkie pojawiające się błędy. Bardzo żałuję, ale tego poziomu perfekcyjności chyba raczej nigdy nie osiągnę (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) )
Dlatego bardzo cenię wszystkie mechanizmy, które pomagają mi w tym, bym, nawet mimo swojej znacznej omylności, mógł pisać dokłądniej.


Faktem jednak jest, że boli mnie to, że rzeczy, które w Perlu, nie mówiąc już o C++, można zrobić bardzo wydajnie, w php zajmują masę czasu. Chciałoby się móc to zmienić.
I choć akceleratory trochę zmieniają tę sytuację, jednak tu potrzebny by był skok wydajnościowy nie o 300-500% (a gdzieś tyle dają akceleratory) a o kilkanaście- kilkadziesiąt razy.
Tego jednak chyba od twórców php wymagać nie możemy. A szkoda...