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]

Swojego czasu trochę nad tym z kumplem debatowaliśmy i doszliśmy do wniosku, że to jest po prostu nie do zrealizowania, tj. nie da się programować w php jak w Javie czy innym stricte obiektowym języku.

Klasy encyjne (istnieje takie pojęcie w ogóle? no w każdym razie mam nadzieję, że wiadomo o co chodzi ), czyli te które reprezentują dane, w php po prostu nie mają sensu. Należałoby je cache'ować, a tego nie da się uzyskać z oczywistych powodów - kod w php działa tylko przez chwilę.

Powiedzmy (na co na pewno sam wpadłeś), że możesz obie klasy wypełnić za jednym przebiegiem wywołując łączone zapytanie do bazy i wypełniając je obie na raz poprzez jakieś, tylko po co? Przekazujesz to potem jakiemuś wyświetlaczowi, bawisz się, grzęźniesz a możesz to mieć w trzech linijkach zwykłego, proceduralnego kodu.

Bynajmniej nie jestem mastah OOP, ale na tyle na ile poznałem php uważam, że nie warto się bawić z nim w takie klasy, reprezentujące rekord bazy danych. Szkoda Twojej pracy. Nie mniej bardzo chętnie posłucham, jeśli ktoś ma jakieś inne doświadczenia. Pozdrawiam.

[halfik]

mnie z kolei interesuje ciut inne zagadnienie: czy warto kodowac caly serwis obiektowo? wydaje mi sie, ze jednak to samo zrobione proceduralnie bedzie dzialalo szybciej, a przy zachowaniu wysokiej czytelnosci kodu, duza modularyzacje, oraz tworzenie dal kazdej z funkcji czegos w stylu CRC, mozna spokojnie uzyskac pozadany efekt.

Czy ktos sprawdzal, czy i o ile szybciej dzialaja serwisy zakodowane proceduralnie, przy powiedzmy min. 20 zadanich wyswietlenia tej samej strony jednoczesnie ?

[LukaszLenart]

Pomysle, ze masz system ktory generuje jakies raporty na stronie.
I te same raporty masz codziennie o 7.00 rano wysylac mailem do szefa (skrypt w php + cron).
Jesli nie masz obiektu to tworzysz dwa osobne skrypty, ktore to realizuja (pobieraja dane z bazy, przetwarzaja i generuja raport), a teraz zmienia sie stuktura bazy i musisz modyfikowac dwa skrypty, zmienia sie sposob wyliczania danych w raporcie i znow musisz modyfikowac dwa skrypty.

Nawet jak wszystko ladnie polaczysz procedurkami to i tak to musisz gdzies upakowac w jeden pliczek i znac kolejnosc wywolywania funkcji (a to juz krok od umieszczenia tego w klasie)


Pozdrawiam

Lukasz

[halfik]

tak, wiem. znam zalety programowania obiektowego, ale nie o to mi chodzilo w pytaniu. ciekawi mnie czy jest sens kodowac w php serwisy w obiektowce, bo przeciez zalezy nam na szybkosci oraz oszczednosci zasobow pamieciowych serwera - dlatego tez ciekawi mnie, co jest szybsze oraz zrzeraz mnie pamieci? A ze obiektowka ma inne zalety to fakt - ciezko pielegnuje sie, czy zmienia kod czegos co bylo napisana strukturalnie - znam ten bol z doswiadcznie :/

[Seth]

Szybsze jest programowanie strukturalne.

OOP nie jest natywne w php. Mimo, ze posiada klasy nadal jest to srodowisko strukturalne i wlasnie na tym polu jest najszybsze.

[DeyV]

Na szczęscie te róznice są na tyle marginalne, że zalety pisania obiektowego aż nadto je przykrywają. Dlatego też CMS który piszemy, ma być w PEŁNI obiektowy.

[LoPMX]

zastanawiam sie jak zdolacie zaprojektowac klasy zwlaszcza wybierajace dane z baz danych np. artykuly, wraz z powiazaniem relacyjnym owych tablic. czy zrobicie moze GOD classes, co jest bledem?

[halfik]

OOP nie jest natywne w php. Mimo, ze posiada klasy nadal jest to srodowisko strukturalne i wlasnie na tym polu jest najszybsze.

o to mi chodzilo. thx. za odpowiedz.

wahalem sie, czy przejsc na OOP, bo faktycznie kod jest jeszcze czytelniejszy i duzo latwiejszy w pielegnacji. Kolejne WWW, ktore bede kodowal napewno beda na klasach.

P.S A jak ma wygladac OOB w php 5? Na ile to juz bedzie faktycznie programowanie obiektowe. i czy bedzie bardziej podobne do JAVA czy C++ - bo mimo duzego podobienstwa w tym jezykach, roznice sa...

[Użytkownik]

Programowanie obiektowe bardziej pasuje mi do porządkowania i UTRWALANIA dużej ilości danych.
Kiedyś chciałem zainstalować forum z klasami (operujące na XML'u). Pliczek "klasowy" był ponad 200 kb.
Dla porownania zwykłe forum, chyba w całości miało 200 kb.

Generalnie podejrzewam, że w php nie jest to w ogóle potrzebne.

[halfik]

oj, jest potrzebne - jezyki obiektowe to przyszlosc.
po prostu przy duzych aplikacjach, jesli cos robimy strukturalnie, jest nieciekawie, a jak pozniej trzeba zmienic jeden, kilka modulow, to czlwoiek sie boi bo wie, ze za chwile cos sie sypnie w zupelnie innym miejscu

[Użytkownik]

oj, jest potrzebne - jezyki obiektowe to przyszlosc.
po prostu przy duzych aplikacjach, jesli cos robimy strukturalnie, jest nieciekawie, a jak pozniej trzeba zmienic jeden, kilka modulow, to czlwoiek sie boi bo wie, ze za chwile cos sie sypnie w zupelnie innym miejscu

W php po prostu nie piszę się wielkich aplikacji.

[Seth]

Pisze (ezPublish, Galaxia, Ambivalence, binarycloud - btw niezla nazwa - etc) ale kosztem wydajnosci.

[halfik]

no ale nawet pomijajac juz duze aplikacje. wezmy pod uwage np. srednich rozmiarow serwi internetowy, w sklad ktorego wchodza: system rejestracji uzytkownika, forum, system logowania, system obslugi ogloszen, system obslugi dzialu download i kilka innych rownie prostych rzeczy. Calosc sklada sie na prosty, aczkolwiek srednio rozbudowany serwis - to wystarczy, zeby odczuc wady kodowania strukturalnego. Pisalem juz serwis takiego rozmiaru (sam jeden musialem kodowac :/) i z doswiadczenia wiem, ze pozniej czlowiek boi sie zmienic dany modul, bo bez odpowiedniej dokumentacji (a ja nie robilem jej w trakcie), nie wiadomo jakie inne jeszcze skrypty korzystaja z danego modulu oraz w ktorym skrypcie, ktore moduly sa powiazane z tym, ktory chcemy zmienic - masssakra owszem, wszytko da sie zrobic, ale kosztem niepotrzebnej utraty czasu oraz nerwow (gdybym mial chociazby najprostsza dokumentacje, zapewne problem nie bylby az tak duzy, ale jednak by byl...)

[LukaszLenart]

Jedna rzecz to prostota zmian, a druga to mozliwosc uzycia raz napisanych klas w innych projektach.

[Pathfinder]

Witam

Swoj maly system buduje tylko na klasach. Strukture klas buduje w stylu bazy relacyjnej. Kazda klasa jest oparta na glownych klasach db, stdio i tpl . Wszystkim zarzadza automatyczny manager ktory ma wszystko dokladnie poukladane, tzn jakie klasy istnieja z czego mozna korzystac, instaluje nowe klasy poprzez odpowiedni wlasny jezyk skryptowy. Moze php 4 jest strukturalny ale mi sie udalo stworzyc samowystarczalny system ktory nie wymaga wiecej niz trzech klikniec by zainstalowac kolejna paczke z modulem. Obslugi zmiennych mam zbudowane tak ze obsluguje to odpowiednia klasa wiec w poszczegolnych klasach wogle nie korzystam z $_POST lub $_GET wszystkim zajmuja sie odpowiednie systemy, tak samo z baza robie $db = new_db() i mam odpowiedni obiekt bazy np mysql lub pgsql lub odbc. Nie wazne jaka baza ,caly czas zmienne wygladaja tak samo. Co do zmiennych wychodzi na to samo czy mam mod_rewrite w apachu wlaczony czy nie. Klasa vars sie wszystkim zajmuje. Caly system zbudowalem tak by kolejne moduly nie musialy przetwarzac danych, dostaja juz odpowiednie dane.
Podsumuwujac obiekty w php mozna swietnie wykorzystac i stworzyc wlasne API lub SDK.

Pozdrawiam

[LukaszLenart]

A czy mozesz udostepnic swoje rowiazanie do wgladu, chcialbym zobaczyc jak to zrobiles?

[radziel]

Witam

Swoj maly system buduje tylko na klasach. Strukture klas buduje w stylu bazy relacyjnej. Kazda klasa jest oparta na glownych klasach db, stdio i tpl . Wszystkim zarzadza automatyczny manager ktory ma wszystko dokladnie poukladane, tzn jakie klasy istnieja z czego mozna korzystac, instaluje nowe klasy poprzez odpowiedni wlasny jezyk skryptowy. Moze php 4 jest strukturalny ale mi sie udalo stworzyc samowystarczalny system ktory nie wymaga wiecej niz trzech klikniec by zainstalowac kolejna paczke z modulem. Obslugi zmiennych mam zbudowane tak ze obsluguje to odpowiednia klasa wiec w poszczegolnych klasach wogle nie korzystam z $_POST lub $_GET wszystkim zajmuja sie odpowiednie systemy, tak samo z baza robie $db = new_db() i mam odpowiedni obiekt bazy np mysql lub pgsql lub odbc. Nie wazne jaka baza ,caly czas zmienne wygladaja tak samo. Co do zmiennych wychodzi na to samo czy mam mod_rewrite w apachu wlaczony czy nie. Klasa vars sie wszystkim zajmuje. Caly system zbudowalem tak by kolejne moduly nie musialy przetwarzac danych, dostaja juz odpowiednie dane.
Podsumuwujac obiekty w php mozna swietnie wykorzystac i stworzyc wlasne API lub SDK.

Pozdrawiam

Wg. mnie to kolejny skrypt wg. idei MVC.

[Pathfinder]

A czy mozesz udostepnic swoje rowiazanie do wgladu, chcialbym zobaczyc jak to zrobiles?

Moge dac Ci kawalek ale na maila. Nie chcialbym udostepniac calego bo jest to jeszcze w fazie rozwojowej i ogolnie wysylam to na taki konkurs. Mam nadzieje ze rozumiesz. Moge dac ci grupe funkcji z klasy instalatora.

napisz mi emaila to Ci odeske <pathfinder at eia dot pl>

[lukaswoj]

Ja jestem zdecydowanie za OOP.
Zgadza się, że w PHP4 obiekty nie są w 100% tym czym być powinny, ale to sie zmieni z czasem, wystarczy popatrzeć co nowego w tej kwestii będzie oferowało PHP5, zmiany idą dobrą drogą.

Ja podobnie jak Pathfinder zrobiłem sobie "systemik" tworzący aplikację WWW w 90% w OOP, wszystko składa się z pojedyńczych modułow, każdy z nich jest klasą, która rozszerza pewną klasę podstawową dzieki czemu dziedziczy wszystkie podstawowe metody wymagane do działania każdego modułu, do tego dochodzą metody specyficzne dla danego modułu.
Wszystkie moduły zorganizowane są w strukturze drzewiastej - jedne są dziećmi innych i jednocześnie rodzicem kolejnych dzieci.
Dodanie kolejnego modułu sprowadza się do wyedytowania pliku konfiguracyjnego i podania kilku podstawowych wiadomości nt modułu, tj. nazwa klasy, plik z szablonem, nazwa modułu, ID modułu i inne.

Całość sprawia, że np w aplikacji, gdzie jest kilka miejsc na stronce, które służą do przeglądania zawartości róznych tabel z bazy danych - wykorzystuje do tego celu jedną klasę a tylko inicjuję ją z odpowiednio innymi parametrami dla danej tabeli. Do tego mam już moduliki pozwalające wybrać tylko porządane kolumny, wiersze, pogrupować rekordy po ileś tam na stronie itd....

Podsumowując - uważam tak jak jeden z poprzedników, że OOP to przyszłość i naprawde bardzo ułatwia wszelkie modyfikacje, odpluskwianie, rozbudowe aplikacji.

Ale sie rozpisałem

p.s.
Wkrótce przedstawie do oceny mój najnowszy projekcik oparty właśnie na tym "systemie".

pozdrawiam