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?

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.

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 ?

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

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 :/

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.

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.

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?

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...

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.

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.

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

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...)

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

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

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

Wg. mnie to kolejny skrypt wg. idei MVC.

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>

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

Dokładnie. W całej rozciągłości zgadzam się z lukaswoj-em. Brakuje jednak tej wielowątkowości w PHP5, jaką zapowiadali, ale później się z niej szybko wycofali. Wtedy taka obiektówka mogłaby być w pełni wykorzystana. Dałoby się zrobić prawdziwie trwałe obiekty, których nie musielibyśmy serializować. Nie wczytywało by się tylu klas za każdym razem przy wywołaniu skryptu.

...i wreszczie php byłoby na tyle skomplikowane, żeby możnaby go było poważnie traktować, a skrypt rozpoczynałoby się

[php:1:f3b4de8dd6]<?php
class myPage extends PHPPage {
(...)
}
?>[/php:1:f3b4de8dd6]



A tak na poważnie, to to co mówisz jest wspaniałe, ale trochę nie przystaje do php. Od tego są inne języki, o bardziej rozbudowanych możliwościach. php ma chyba za dużą narośl kompatybilności, żeby udało się to wprowadzić z powodzeniem. Podobnie jak choćby przestrzenie nazw. Poza tym - to zwyczajnie i bez żadnego argumentu - nie pasuje do języków skryptowych - byłaby wirtualna maszyna php, albo php Framework?



A w jaki sposoób wykorzystujesz serializację do przechowywania obiektu między wyołaniami skryptu? Przecież dwie instancje skryptu mogą działać w tym samym czasie? Tak swoją drogą w prawdziwych serwerach aplikacji obiekty są jak najbardziej serializowane automatem, żeby zaoszczędzić RAM, ale to już inna bajka.

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.

W A1 Internet poradziliśmy sobie w ten sposób, że połączyliśmy klasy generowane przez DB_DataObject (http://pear.php.net/package/DB_DataObject) z klasami - kontrolerami poszczególnych stron albo modułów na stronie.

W praktyce wygląda to tak, że w oparciu o każdą z tabel w bazie danych automatycznie tworzona jest klasa - model (DAO), w której możemy nadpisać np. metodę wyciągającą, uaktualniającą albo usuwającą dane. Możemy też dopisać nowe metody.

Zazwyczaj z DAO korzysta się w taki sposób:
[php:1:b04b93a0cc]
<?php
$article=&new Model_Article;
$article->get('id',2343);
$article->find(); // tworzy zapytanie SQL i wykonuje je
$article->fetch(); // pobiera pierwszy (i jedyny) z wyników
print($article->title); // teraz możemy zobaczyć tytuł artykułu
?>
[/php:1:b04b93a0cc]

Tak mniej więcej wygląda kontroler strony wyświetlającej konkretny artykuł, tyle że bez ostatniej linii , bowiem obiekt $article przekazujemy do szablonu.

A co zrobić jeśli chcemy wyciągnąć kilka artykułów? Wycwaniliśmy się i jeśli chcemy np. wyświetlić 10 ostatnich artykułów, dodajemy do klasy DAO taką oto metodę:

[php:1:b04b93a0cc]
<?php
class Model_Article {
// [...]
function findLast($limit=10) {
$this->selectAdd(); // w DB_DataObject kasuje listę pól
$this->selectAs(array('id','title','time_added','abstract','author')); // wyciągamy tylko niektóre pola
$this->orderBy('time_added DESC');
$this->limit($limit);
$this->find();
}
//[...]
}
?>
[/php:1:b04b93a0cc]

Z kolei w klasie - kontrolerze strony wyświetlającej ostatnie wiadomości dajemy taki oto kod:
[php:1:b04b93a0cc]
<?php
$article=&new Model_Article;
$article->findLast();
$this->publish('article',$article); // tutaj przekazujemy obiekt $article do szablonu
?>
[/php:1:b04b93a0cc]

Szablon zaś wygląda tak:
[xml:1:b04b93a0cc]
<div id="articlelast">
<dl>
{while $article->fetch()}
<dt>
{$article->title}<br />
<small>{$article->time_added}</small>
</dt>
<dd>
{$article->abstract}
</dd>
{/while}
</dl>
</div>
[/xml:1:b04b93a0cc]

Powyższy szablon wykorzystuje naszą klasę A1_Template (znaną też jako Template_A1), którą niedługo udostępnimy na licencji LGPL.

Powiązaniami relacyjnymi tabeli article z innymi tabelami zająć się może DB_DataObject. Związane z tym metody wywołać można w klasie - kontrolerze strony albo ewentualnie nadpisanej metodzie w klasie DAO.

Jeśli ktoś zna lepszy sposób na rozwiązanie tej kwestii, ma u mnie zimne piwo (lub czasopisma).

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).

Wyborem odpowiedniej klasy zajmuje się skrypt analizujący adres URL i wywołujący na jego podstawie odpowiednią stronę (klasę i szablon) oraz obsługujący pluginy odpowiedzialne za obsługę bazy danych, autoryzację, itd.



Muszę tutaj polemizować, bowiem jakiś czas temu stworzyłem całkiem spory serwis właśnie w opisany przez Ciebie sposób (tyle że AdoDB zastąpiłem inną klasą). Ów serwis to http://mp3.wp.pl. Efekt? Takie rozwiązanie sprawdza się pod kątem wydajności (na tyle, że wąskim gardłem stał się Smarty), natomiast 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.

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.



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.

owsze, pewnie ze kod napisany strukturalnie, bedzie dziala rownie szybko, efektywnie, bedzie czytelny (jesli koder nie da... ;-) ), ale mimo wszystko przyszlosc to OOP. a dlaczego? wystarczy poczytac z teorii OOP i wszsytko wiadomo o zaletach. upieranie sie przy strukturalnym nie jest dobra rzecza, w przypadku gdy do dyspozyji ma zostac oddane calkiem niezle OOP <- no bo fakt, ze w 4 bylo kiepskie i przez to go nie uzywalem. przyszlosc jednak wyglada obiektowo i to calkiem milutko :wink:

W 4 bylo kiepskie ? I dlatego go nie uzywales ? Nie zartuj sobie ... Albo masz nikle pojecie o OOP w php 4 albo masz male pojecie wogole o programowaniu obiektowym (a moze ja sie jeszcze nie poznalem na tym dosc dobrze i klepe bzdury - nie wykluczam takiej mozliwosci ). W php 5 nie widze zadnych nowych bajerow, ktore mialyby w _znaczacy_ sposob wplynac na to jak bede projektowal i kodowal aplikacje w php5. Mnie tam najbardziej w php5 cieszy to ze w koncu na serwerach beda instalniete najnowsze wersje php - jak ktos ma php5 to bede wiedzial ze aplikacja ruszy mu na 100% i nie trzeba bedzie sie martwic o kompatybilnosc z php 4.1.x , 4.2.x etc

pozwole się wtrącić...
buhehe dobry powod dobry
w php5 nie widzisz zadnych bajerów ? haha ja o nich czytam od dwoch dni na porządnie już i dalej nie moge sie połapać ile w końcu tych bajerów jest, i albo nie czytałeś nic o php5 jeszcze albo to ty nie masz pojęcia o php dokładniej wersji z cyferką 5 :wink:
I teraz taka moja wizja topicu ...
hmmm.... trudno się mi wypowiadać gdyż poznałem troche php (inaczej mówiąc buduje aplikacje w php do których jest język ten przeznaczony bez problemu, i jedyne do czego sięgam to manual) a inne języki troszkę mniej (właściwie to liznałem :wink: ) ale jestem jednego pewien... stosunku do aplikacji internetowych....
OOP jednoznacznie wygrywa w przypadku średnich i dużych aplikacji i tutaj nie ma kwesti spornych bo tak właśnie jest, kto się sprzecza z tym moim zdaniem, chyba z takimi aplikacjami nie miał doczynienia (może się mylę), ale problem pozostaje przy tych mniejszych.... tutaj wydaje mi się że o pełnym OOP-ie można zapomnieć a to z uwagi na brak wyraźnej potrzeby jego rozplanowania , implementacji itp w małej zastosowaniach, w takich przypadkach wydaje mi się że kod pisze się poprostu prawie z ręki
Pozdrawiam patS.
UPDATE by my self -> poprawiono nie zroumiałość wypowiedzi [size=9][/size]

Patrycjuszu nie zrozumiales o co mi chodzilo (moze nie wyrazilem sie zbyt jasno ... ). Oczywiscie ze w php5 jest dodanych duzo nowych bajerow - nie zaprzeczam temu. Chodzi mi raczej o to ze zaden z tych bajerow nie sprawi ze moj kod bedzie bardziej obiektowy. php 5 wprowadza wiele nowych funkcji ktore ulatwia programowanie obiektowe, ale to nie znaczy ze php 4 nie jest obiektowe. Przy odrobinie zaparcia i samodyscypliny w php4 mozesz kodowac tak samo obiektowo jak w php5.

A czy nie uważacie, że jeśli uprzeć się tylko na programowaniu strukturalnym to dużo uzyskać można przez implikację poprostu bardzo dobrze zaprojektowanych funkcji, tworzących spójną całość, a jednocześnie zachowujących (w jakimś przynajmniej stopniu) odrębność(by przy zmienie jednej "nie sypnęło" nam się coś gdzie indziej)?

Mozna tez uzywac 286 i dyskietek zamiast tydsku, tylko po co sobie utrudniac prace ?

Pewnych rzeczy nie uzyskasz bez OOP. Poza tym nie mozna stac w miejscu skoro swiat jest dwa kroki przed nami
Niedlugo pewnie standardem bedzie AOP (Aspect Oriented Programing) a bez znajomosci OOP nie da sie tego ugryzc.

ja tez pisze swoj maly systemik na oop ;p ale wole nie pokazywac kodu bo sie chce w ten sposob oop nauczyc ;p http://kserv.info/~keedy/ jednak pokaze ale nei kod ;p a template jest pierwszy lepszy ;p

Ja uczę się OOP tylko dlatego, że przyszły pracodawca może wymagać odemnie projektowania/programowania opartego o obiekty.

@trax
W pełni zgadzam się z Twoją wypowiedzią.
Programować trzeba z głową, a programowanie strukturalne jest jednak bardziej intuicyjne niż obiektowe.

@Seth
Możesz powiedzieć co to za rzeczy ?

To akurat jest bzdura. Można nie lubić OOP albo być bardziej biegłym w programowaniu strukturalnym, ale jak człowiek, który źle się czuje w OOP, tak twierdzi, to nie jest to chyba obiektywne. Poza tym, OOP wprowadzono właśnie dlatego że jest bardziej intuicyjne... można mieć swoje zdanie, ale nie można negować faktów.

Geez... jaka bzdura...
Jak napisal hawk: nie mozna negowac faktow.
Jesli dla kogos tablica o nazwie "ble" ktorej pierwsze pole uznajemy za id, drugie za szerokosc a trzecie za wysokosc, jest wedlog kogos BARDZIEJ INTUICYJNYM opisaniem kwadratu niz obiekt klasy Kwadrat z wlasciwosciami id, szerokosc i wysokosc, to ja gratuluje obiektywizmu.

Wypowiedzi na forum nie muszą być obiektywne, bo nie jesteśmy (przynajmniej ja) naukowcami, którzy mogą obiektywnie zbadać dane zagadnienie. Poza tym bazuję tylko na swoim doświadczeniu i obserwacjach innych.

Nie neguje faktów i do opisu kwadratu pewnie użyłbym obiektu, ale powiedziałem co powiedziałem, ponieważ nawet na tym forum często można przeczytać posty, w których ludzie mają problemy z obiektami, które nie mają fizycznych odpowiedników w świecie rzeczywistym. Parę razy widziałem też wypowiedzi w stylu to nie jest OOP tylko funkcje zgrupowane w klasę. Z tych wszystkich postów wynika, że jednak ludzie mają problemy z OOP i nie jest to tak intuicyjne rozwiązanie jak wszyscy mówią.

Ludzie mają też problemy z programowaniem strukturalnym. Większość postów tutaj to jednak problemy z różnymi funkcjami i kodem czysto proceduralnym. Z tych wszystkich postów wynika, że jednak ludzie mają problemy z programowaniem strukturalnym i nie jest to tak intuicyjne rozwiązanie jak wszyscy mówią. Twoja własna teoria .

A problemy z OOP wynikają z tego, że ludzie biorą się do niego bez wcześniejszego przygotowania, z wielkimi oczekiwaniami (takie wspaniałe, intuicyjne, itd), za to ze sporym bagażem nawyków/przyzwyczajeń z programowania strukturalnego. I stąd się biorą problemy.

Ja np najpierw nauczyłem się obiektowości w C++, a potem zacząłem pisać w C. I nigdy nie miałem problemów z OOP. Za to miałem problemy z organizacją modułów w C .

Seth: Czy ten Aspect Oriented Programing (AOP) będzie dostępny w php czy ASP.NET ? Opisz troszke o nim jakbyś miał czasu

na necie jest gdzies przyklad programow napisany aspktowo i to juz jest wyzsza szkoła jazdy. w php napewno nie ma. niestety nie pamietam jakie jezyki go wspieraja mozwe c# albo D

To witaj w klubie Tez zaczynalem od C++, aczkolwiek jeszcze wczesniej znalem Object Pascala.

Zgadzam sie z przedmowcami, ze OOP swietnie sluzy do budowy srednich i wiekszych aplikacji. Do malych sprawdza sie tak samo dobrze, tyle ze w innych jezykach, bo jest bardziej intuicjne. Problem z php jest taki, ze skrypt wykonuje sie raz, a pozniej wszystko gubi i trzeba zapisywac albo w bazie, albo w sesjach. I to "psuje obiektowosc". Nie da sie zrobic takich rzeczy jak np. w Javie, ze piszesz sobie klase, przy kazdym polu dajesz @hibernate.property column="nazwa odp. kolumny w bazie danych" i pozniej z bazy wydobywasz od razy gotowy obiekt, nie bawisz sie w jakies SQLe itp. Zmieniasz jedno pole, dajesz update i masz wszystko ladnie odswiezone w bazie. To jest wlasnie Aspect Oriented Programming.
Czy chociazby programowanie zdarzeniowe jak w C++ Builderze czy ASP.NET.
Bez OOP ani rusz.

Chcialem napisac kiedys swoj wlasny framework obiektowy do budowy aplikacji w php, ale w koncu sie wycofalem i robie go w C++. Dzieki temu wiele udogodnien mam niemal za darmo przy duzo wiekszej wydajnosci i na dodatek moge robic rzeczy, ktorych w php nigdy by sie nie dalo dobrze zrealizowac:
- zabezpieczenie kodu zrodlowego
- niezaleznosc od interpretera i bibliotek - mozna przeciez linkowac statycznie
- "trwałosc" obiektow
- wskazniki (jak jest trwalosc, to wskazniki nagle staja sie b. potrzebne)
- dobry odsmiecacz (czymze jest marne zliczanie referencji php)
- wielodziedziczenie (glownie do wyjatkow)
- wielowatkowosc (no do apl. internetowych moze mniej przydatne, ale kto wie)
- rozne zaawansowane struktury danych (STL)
- tysiace dobrych bibliotek dla roznych zastosowan w tym do aplikacji rozproszonych (CORBA, RMI, RPC) i rownoleglych (PVM).
- lepsza integracja z innymi programami, w tym syst. baz danych (nie spotkalem systemu, ktory by nie dawal API do C)
- setki gotowych narzedzi takich jak kompilatory, debuggery, IDE itd.

Jedyne czego brakuje to paruset klas dla ulatwienia pisania aplikacji WWW, ale wlasnie nad tym pracuje. Chyba latwiej dorobic takie klasy niz probowac implementowac wszystko co na gorze w php? Ale moze sie myle.

Z drugiej strony troche trudniej uzyskac dobra przenosnosc, ale jest to mozliwe i trud sie oplaca. Zreszta przenosnosc wcale nie jest tak wazna po stronie serwera.

Jednym slowem OOP rzadzi, tyle ze nie w php. ((

1) php a Java to jest, niestety, gigantyczna przepaść, jeżeli chodzi o rzeczy z wyższej półki. Nie ma co się oszukiwać. W php nie robi się systemów bankowych itd.

2) Własny framework obiektowy w C++ ? Przedsięwzięcie ambitne i szlachetne, ale IMHO skazane na porażkę. Dlaczego?

Nad mechanizmami garbage collection pracowało wiele ludzi, mądrzejszych od nas. To zbyt zaawansowane, by ktokolwiek mógł ot tak sobie napisać dobry garbage collector. Nie da rady.

Brakuje ci tylko tylko odpowiednika serwera JSP, trochę EJB, itd. No może jeszcze Swinga przepisać. Skoro nad JSP pracowało (dalej pracuje) przez dłuuugi czas wielu ludzi, skoro ASP.NET powstawał kilka lat, to Ty napiszesz to w jeden dzień .

Życzę powodzenia i daj znać jak skończysz.

@hawk: wiem ze moze jestem niepoprawnym optymista, ale Ty widze jestes niepoprawnym pesymista. Jakby wszyscy tak mysleli, to nie powstawaloby nic nowego.

Co do GC to jest to akurat jedna z prostszych rzeczy. Wlasnie po to naukowcy pracowali przez wiele lat, zeby mozna bylo korzystac z ich doswiadczenia, a nie uzywac sposobow chalupniczych. Tylko przeczytac troche literatury, zrozumiec i mozna kodowac. C++ ma taki model wykonawczy, ze nawet jak wezmiesz sredniej jakosci garbage collector to i tak bedzie dzialal lepiej niz ten w Javie (ten w Javie swoja droga tez jest niezbyt dobry o czym wypowiedzieli sie juz wieksi specjalisci, chociazby tacy jak J.H.Boehm). Powod: w Javie prawie wszystko alokujesz na stercie, w C++ prawie wszystko na stosie. Dobra, ale to sa szczegoly techniczne, wracam do tematu.

Kolejna rzecz: nie mam zamiaru tego napisac w 1 dzien. Widze ze czytasz w moich postach rzeczy, ktorych nie napisalem.

Dla C++ nie ma na razie takiego pakietu, wiec jest miejsce na to zeby taki napisac. Nie twierdze, ze bedzie lepszy czy gorszy. Na pewno pod pewnymi wzgledami bedzie lepszy (wydajnosc, zuzycie zasobow) niz takie powiedzmy JSP a pod innymi gorszy (C++ jest trudniejszym jezykiem, gorzej z przenosnoscia).

Swinga przepisywac nie musze bo jest: wxWidgets, QT, GTK+. Do wyboru do koloru.
Zreszta po kiego grzyba swing do aplikacji WWW? Pomysl zanim napiszesz.

A moze generowanie obrazkow w locie? ImageMagick. Dziala i na Win, i na Lin, i na Uniksach.

EJB nie jest mi potrzebne - to ma byc do srednich aplikacji projektowanych obiektowo, a nie do systemow rozproszonych. Oczywiscie cos na ksztalt EJB bedzie - w zasadzie EJB to w wiekszosci RMI, a przeciez odpowiednik RMI w C++ jest: CORBA. Przez srednie aplikacje rozumiem takie, dla ktorych J2EE jest za duza armata, a php jest za bardzo ograniczone (w sensie projektowania architektury aplikacji, nie mozliwosci)

I pamietaj tez, ze php powstalo jako pare skryptow Perla do latwiejszego pisania CGI. Mysle, ze gosc, ktory tworzyl php od podstaw tez sie spotykal z opiniami takimi jak Twoje: "Stary, daruj sobie, wszyscy koduja CGI w Perlu i C, nie napiszesz nic mocniejszego niz kompilatory C albo Perla, nad ktorymi pracowano wiele lat..."

Tak czy inaczej latwiej dopisac pare bibliotek do C++ niz wymyslac nowy jezyk.
Prawie nic nie trzeba samemu pisac - tylko sie rozejrzec, wybrac, zebrac, ujednolicic i wygenerowac dokumentacje.

ale, do %#$^%, chłopie. Jak tak bardzo lubisz C++, jak widzisz tyle zalet pisania w Javie, i jak tak nisko cenisz php, to po %$^% siedzisz na tym forum?
Mało for programistycznych, gdzie więcej ludzi będzie potrafiło docenić twoją wiedzę, potencjał, pomysł i być może jeszcze Ci w nim pomogą?
Dlaczego musisz udowadniać to nam?
Najwyraźniej mamy wiele powodów skłaniających nas do pisania w php (już wymieniane: prostota, przenośność, dostępność, spore możliwości i popularność) i stwierdziliśmy, że chcemy w nim pisać.
Wielu z nas pracuje również w innych językach (głównie Java) jednak nie pozbawia nas to przyjemności (a więc całkiem miłego sposobu na zarabianie pieniędzy) pisania w tym języku.
Tym bardziej, że da wielu jest to jedyna metoda na szybie wejście na rynek (jednak chyba nie trudno zauważyć, że jest znacznie mniejsze zapotrzebowanie na młodych (nie wiekowo, a doświadczeniem) programistów w C++, niż w php).
Nie zawsze ma to pozytywny dla tego języka efekt, ale wielu z nas w innym przypadku nie mogłoby sobie pozwolić na to, by na poważnie zająć się programowaniem.

A że nie jest to język do wszystkiego? A który jest?
W każdym razie - pisząc obiektowo nawet proste skrypty
a) oszczędzamy czas poświęcany na pisanie (co prawda często kosztem czasu poświęconego na projekt, ale cóż - wszystko ma swoją cenę )
b ) piszemy bezpieczniej
c) łatwiej jest pracować w zespole (jak dla mnie nie widzę innej możliwości pracy zespołowej)
d) uczymy się nowych technologii, które są niezbędne we wszystkich innych językach programowania (jednak w php podany wyjątkowo przejrzyście i w prosty sposób )

Czy tak bardzo Ci to przeszkadza?

@DeyV:
Przecież ja nikogo nie odmawiam od pisania w php!

Też używam php do wielu celów i dlatego wszedłem na to forum. Chociażby dzięki temu weryfikuję też swoje zdanie na temat php, jego możliwości i pułapek, a nóż rozwiążę jakiś problem, albo znajdę odpowiedź na jakieś pytanie.

Dyskutowaliśmy o przydatności OOP w php. I podałem tylko kontrprzykład, a Ty to głupio wziąłeś osobiście. Czasem trzeba umieć spojrzeć trochę bardziej krytycznie, również na "swój ulubiony język". Mnie też C++ i Java czasem doprowadzają do szału (np. C++ nie ma dobrej jednolitej biblioteki standardowej, a Java zajmuje tyle RAMu, że ciągle muszę dokupywać).

Mój porzedni post nie miał na celu wykazania, że php jest słabe i nie warto w tym pisać, a jedynie że konkretnie w tym zastosowaniu C++ jest lepszym wyborem. Hawk z tym polemizował ("Przedsięwzięcie ambitne i szlachetne, ale IMHO skazane na porażkę."), więc napisałem bardziej szczegółowe uzasadnienie.

A porównania php i Javy/C++ będą, bo twórcy php chyba sami o to zabiegają skoro ściągają model obiektowy niemalże żywcem z Javy i próbują tym samym z php zrobić Javę. Mnie się to nie podoba - bo nie jest mi potrzebna druga Java, a lepsze php. Ciekawe kiedy dodadzą JIT, jako główny system template'owy zaczną promować bibliotekę Struts, a interpreter php przemianują na php-VM.



Z tym się zgadzam całkowicie. Do punktu (a) bym dodał, że czasem minuta więcej poświęcona na projekt może zaoszczędzić parę dni implementacji. Wiem z własnego doświadczenia.

Ok, peace 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 )
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 ) 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ę )
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...