"Następnie utworzyliśmy klasę z obiektu." - Miało być obiekt klasy :-) Tak to jest jak się pisze wieczorem.

Dzieki! Tego mi bylo trzeba :) Ale w artykule pojawil sie blad:

[code]$Osoba1 = new Osoba();
$Osoba_Zenek->imie = 'Zenek';[/code]

zamiast $Osoba1 powinno byc $Osoba_Zenek

Pozdrawiam i czekam na kolejne czesci.

Czy PHP obiektowe można podpiąć do bazy danych?
Czy baza danych zarządzana obiektowym PHP różni się jakoś od bazy danych zarządzanej "zwykłym" PHP? Chociażby taka zwykła relacyjna baza, którą na pewno łatwiej stworzyć niż hurtownię danych i nie potrzeba jakiś specjalistycznych narzędzi.

Tak, w PHP masz między innymi klasy MySQLi oraz PDO do obsługi bazy danych (pierwsza obsługuje tylko MySQL, druga kilka baz danych).
Baza danych, niezależnie od tego jak się do niej podłączysz i będziesz wykonywał zapytania - niczym się nie różni. Różnic się sposób dostępu do niej który jest podobny do tego co tu opisałem.
Swoją drogą nie ma czegoś takiego jak "zwykłe" i "obiektowe" PHP. Obiektówka to po prostu inne podejście do tworzenia aplikacji, oraz do pisania kodu.

Istnieje kilka zasad których należy się trzymać przy programowaniu obiektowym. Mowa tu o hermetyzacji, polimorfizmie, dziedziczeniu czy abstrakcji. Ale na początku nie chciałem o tym pisać żeby nie zawalić użytkownika zbyt wieloma informacjami na raz.

Wszystko wyjaśni się w następnych częściach.

No... Autor jak widzę wziął sobie do serca to co napisałem w jednej z porad (o empty i isset). Początki zawsze trudne, ale myślę, że będzie lepiej :)

Czy w tekście o konstruktorach i destruktorach skupisz się na jakiejś konkretnej wersji czy podasz także różnice między wersjami (inne nazewnictwo)?

Można by stopniowo wspominać o rzeczach nadchodzących z nowszymi wersjami. Na serwerach są głównie gałęzie 5.1, ale śmiało wchodzą 5.2 i gdzieniegdzie 5.3 już. Są pewne zmiany w nich dochodzą także nowe rzeczy jak choćby przestrzenie nazw, a w planach jest "narzucanie typów" zmiennym oraz wiele innych drobiazgów ułatwiających programowanie w związku z choćby wspomnianym w poradzie this (ma działać w funkcjach anonimowych) :)

Nie radzę zaczynać i tłumaczyć wzorców architektonicznych. To bagno ;) Zwłaszcza MVC, które ma tyle interpretacji ilu jest programistów :D Można jednak wspomnieć o wzorcach projektowych, bo to się często przewija a mało kto to rozumie z początkujących. Dla przeciwwagi jeszcze o antywzorcach. Bo to zabawne ukazanie sytuacji, gdy się przedobrzy w którąś stronę ;)

@thek, musisz mi wybaczyć ale nie ja jestem autorem tych dzieł na temat isset() oraz empty(). Za to możesz znaleźć tam mój komentarz.
Tutaj na DI dotychczas opublikowałem tekst "PHP a bezpieczeństwo" oraz "CSS - przepis na piękno".

Myślałem o skupieniu się na wersji 5.x. Chyba nie ma sensu rozgrzebywać starszych wersji PHP. Głównie dlatego że od dawna nie widziałem serwera z PHP4. No nie licząc klientów których serwisy stoją już X lat.

Osobiście piszę pod wersję 5.2/5.3. Nie ma problemu z serwerami pod tę wersję PHP. Rzeczy nadchodzące to już nie obiektówka. To przyszłość. Gdy stanie się teraźniejszością to może trafić w którąś część tekstu ale nie spodziewam się że aż tyle będę je przygotowywał :P Jednak na pewno nowości to dobry temat na artykuł.

Osobiście żadnych antywzorców nie znam. Coś co zakwalifikowane zostało powszechnie jako wzorzec projektowy na ogół jest w jakiś sposób przydatne. To jak z młotkiem. Możesz nim przybić gwoździa ale równie dobrze można się nim puknąć w głowę. Kwestia komu go dasz do ręki.
Pisałem że pod koniec będzie o wzorcach projektowych (ogólnie - do jakiej warstwy aplikacji należą, na czym polegają itp - postaram się opisać te popularniejsze).
O MVC akurat wspomnę (przyda się info o nim przy wzorcach projektowych) ale dalej raczej zagłębiał się nie będę - może w przyszłości. Ilu programistów tyle rozwiązań. Wszystko zależy od tego co potrzebujemy.

No i na przyszłość porównaj nazwiska pod tekstami proszę Cie :-) Jak już mówiłem - tamte teksty o __call() oraz isset() nie są moje.

Stwierdziłem, że Ty jako autor wziąłeś sobie do serca uwagę, iż teksty w dziale Porad nie powinny być na tematy banalne. Tyczyła ta uwaga wszystkich autorów piszących w Poradach. Nie tylko Leszka. Wszystkich redaktorów, którzy zamierzają się łapać za porady z języków czy dialektów. Bo pewnie na PHP się nie skończy jak mniemam, ale zostanie to rozszerzone o SQL i JS oraz ich frameworki (jQuery, MooTools, extJS) czy dialekty (MySQL, PostrgeSQL, MSSQL, OracleSQL) tychże. Niewątpliwie temat regexp-ów będzie liźnięty, bo to popularna obecnie rzecz, a sprawiająca wiele problemów początkującym.

Co do php niższych niż 5 to są. Zazwyczaj przełączane przez htaccess. Wiem bo sam kilka takich zabytków obsługuję. Skrypty stare, ale przepisanie ich na identyczny w php5 to karkołomne zadanie. Lepiej napisać od nowa :D

Co do wzorców to nie myl projektowych z architektonicznymi. MVC jest architektonicznym. Projektowym jest choćby Factory lub Singleton.

Jeśli chodzi o nowości to polecam śledzenie php internals lub wrzucenie do przeglądanych stron blogi osób, które go śledzą i opisują oraz komentują propozycje. Przykładem takiej osoby jest W. Soczyński :) Na jego blogu jest wiele nowości w tym temacie. Sam go czytam i czasem komentuję wpisy.

Artykuł o nowościach - jeśli powstanie - powinien objąć rzeczy najbardziej przydatne, a rokujące największe szanse na wejście szybko do wersji stabilnych.

Antywzorce w dużej części możesz znaleźć w Wikipedii. Najpopularniejszym i najbardziej znanym jest spaghetti-code :)

Myślę, że najlepiej tylko z grubsza wytłumaczyć temat. Jeśli ktoś jest niezbyt zainteresowany to rozwijanie wątku go uśpi jako dłużyzna. To zrobił Leszek. Dużo kodu - mało konkretów. Z całego artykułu wystarczyło by gdyby zamieścił ostatnią tabelę wyników i wytłumaczenie dlaczego tak, a nie inaczej, czyli to co ja mu w komentarzach do owego artykułu zrobiłem.

Jeśli czytelnik będzie zainteresowany to i tak na poruszane tematy znajdzie inne artykuły i źródła. W końcu na tym polega praca informatyka - nieustannej nauce i szukaniu rozwiązań.

@thek, spaghetti-code to nie antywzorzec. To po prostu głupota programisty. Ale ja tam ich rozumie. W końcu są biczownicy, czy też ludzie którzy zakładają sobie pod skórę metalowe kółka i się wieszają na sznurkach...

O internals mówić mi nie musisz. Jestem zawodowym webdeveloperem i chyba doskonale wiem, tak jak ty, że trzeba być na bieżąco w swojej dziedzinie. Wedle zasady - kto się nie rozwija to się cofa.

Pamiętaj też że tekst jest do osób które się UCZĄ OOP. Taki ktoś nie będzie się pakował w PHP4. A jeżeli już to pewnie i tak miał z nim do czynienia. A o tym że jeszcze je znajdziesz pisałem komentarz wyżej. W końcu wszyscy na hurra nie przepisali tego co mieli.

Pokaż mi proszę gdzie pomyliłem MVC i wzorce projektowe. Napisałem tylko że omawiając wzorce projektowe wspomnę o MVC, z uwagi na to, że warto wspomnieć który wzorzec do jakiej warstwy MVC należy. Może zbyt jasno się nie wyraziłem.

Co do reszty tekstów to nie ma się co zapędzać. Jak skończę pisać o OOP to czas pokaże o czym warto będzie napisać. Może wyłoni się jakiś pomysł po drodze.

Jeszcze jeden drobiazg @thek. Teksty w dziale porad zależą od ich autorów. Ja piszę o tym co uznam za stosowne. Ewentualnie podejmę się tematu który ktoś zasugeruje. Co do samych tekstów uwagi kieruj bezpośrednio do ich autora bo tylko on ma na nie wpływ.
Jeżeli masz sugestię albo uwagi odnośnie moich tekstów to chętnie je wysłucham i się do nich odniosę. Jak żyję jeszcze nie miałem powodów by uważać się za nieomylnego. A kiedy się pisze tekst na kilka stron to czasami można coś przekręcić :-)

Pozdrawiam i dzięki za zainteresowanie.

Paint master

"spaghetti-code to nie antywzorzec" to jest antywzorzec, a nie tylko zła praktyka programistyczna. Poza tym spaghetti-code wynika nie zawsze ze złego programowania, ale wprowadzania optymalizacji, które zaciemniają go. Przykładem są pętle. Można je na kilka sposobów rozwiązać. Takie foreach jest bardzo wygodne, ale o wiele szybsze jest posłużenie się pętlą while. To wychodzi w sytuacjach gdzie zależy nam na ogromnej wydajności. Mocno obciążone serwisy, krytyczne sekcje kodu. Tam obiektówka bywa mało wydajna. Poza tym jako webdeveloper wiesz dobrze, ale o tym nie wspomniałeś, że tak zwana "warstwa abstrakcji" to zmniejszenie wydajności. Im ich więcej tym program wolniejszy. To dlatego dobrze zrobiona obiektówka jest z reguły wolniejsza niż dobrze napisana i robiąca to samo partia kodu strukturalnego. Niestety w całym zachwycie nad OOP mało kto o tym wspomina. Potem powstają dziwolągi silące się na ukazanie jaki to programista jest super bo użył tyle technik obiektowych, a kod chodzi jak ślimak, bo koleś przedobrzył z dziedziczeniem, interfejsami, refleksją kodu czy metodami magicznymi. A te 2 ostatnie tak jadą po wydajności, że zarżną każdą aplikację, jeśli są w nadmiarze. Tak samo używanie bibliotek niektórych w PHP do wydajnych nie należy. Konkretnie SPL. Niech ktoś porówna wydajność operacji na katalogach funkcjami do ich obsługi i obiektowej DiretoryIterator.

Antywzorców jest trochę i odnoszą się nie tylko do samego wyglądu kodu czy sposobu jego implementacji, ale także choćby kontaktu na linii programista - klient czy podejścia managerów do programistów i projektu. Nie pamiętam jak on się nazywał, ale jest antywzorcem choćby: "jestem managerem i mogę gadać głupoty o rzeczach, na których się nie znam, a Wy i tak musicie mnie słuchać" ;) Tak więc myślę, że artykuł o antywzorcach mógłby by być takim zabawnym oderwaniem od typowego dłubania w kodzie i wyjaśniania problematyki. Wprowadził by też młodszych w problematykę tego czego unikać pracując w firmie i co "zlewać" robiąc swoje. Typu właśnie manager, który gada głupoty, nierealne do wykonania. Sam miałem podczas egzaminu na studiach taką sytuację. Egzaminator dał nam zadanie praktyczne do wykonania (egzamin miał 2 części: teoria i praktyka). Gdy zaoponowaliśmy twierdząc, że to bzdura co nam dał, zagroził, że tych sprzeciwiających się wyrzuci z egzaminu z oceną niedostateczną. Na 10 minut przed końcem egzaminu jednak sam egzaminator zauważył że to co nam dał jest awykonalne używając wymuszonych na nas założeń. Zdał tylko jeden koleś. Bo miał gdzieś co dał egzaminator jako założenia i zrobił zadanie tak jak on uważał, że powinno być. Bo tylko jego program działał.

Najpewniej ja źle odebrałem to o MVC i wzorcach lub odniosłem mylne wrażenie z kontekstu akapitu. Myślę, że czytając mój komentarz powyżej inne osoby jakby co się "naprostują", jeśli odebrały fragment podobnie. Co do artykułu to nie sądzę, żeby można się go czepić. Co do przyszłego artykułu to polecam zwrócić uwagę nie tylko na this, ale i self. Wiele osób ma z tym problemy, a najgorsze jest to, że sam język pozwala ich używać zamiennie w pewnych przypadkach czyli możemy napisać $this->zmienna albo self::zmienna i PHP nawet nie zająknie się. Dla wielu osób jest to nielogiczne, ale kod działa ;)

Można by tez przy okazji OOP napisać aby nie stosować OOP tam gdzie nie jest to potrzebne.
Wszystko teraz się robi programując obiektowo i jest to niedobre naduzycie jak każde inne.
Ja uważam, że OOP można pisac poszczególne warstwy odpowiadające np. za komunikacje, wysyłke maili, prezentacje, cały framework tez może byc OOP, ale żeby np. pojedyncze kontrolery w takim frameworku pisać obiektowo to już jest bez sensu. Z wyjątkiem sytuacji gdy to jest uzasadnione bo np. kontrolery sa bardzo duże.

@thek, wybacz ale moim zadaniem stanowczo przesadzasz. Gdyby do każdej głupoty jaką wymyśli jakiś samozwańczy "programista-artysta" przypisywano by nazwę to chyba by trzeba było zrobić drugą wikipedię. Ja wiem że niektórzy programiści uwielbiają wymyślać na wszystko terminy ale chyba każdy młody tak ma. Ja i większość ludzi z którymi miałem do czynienia takie praktyki kwitowało w jeden sposób. Do programisty-artysty: "Idź stary zobacz czy Cie na polu nie ma" :-)

Co do wydajności to zgodzę się z Tobą tylko połowicznie. Kod ma być czytelny. To podstawa. Optymalizacje robi się tam gdzie po profilowaniu znajdzie się wąskie gardło. W każdym innym przypadku dokłada się po prostu serwer. Uwierz mi że dzisiaj są one tanie jak barszcz. Tylko te najbardziej obciążające operacje w serwisie optymalizuje się aż do bólu.
Jeżeli chodzi o abstrakcję to przypominam to co napisałem wyżej o młotku. Widziałem twory które potrafiły załadować 2000 obiektów na wywołaniu strony. Właściciela obchodziło to by całość chodziła co robiła należycie. Także nie ma co popadać w skrajności. Ja wolę czytelny kod od wydajnego jeżeli wydajność jest na zadowalającym poziomie. Zresztą w najgorszym wypadku można coś przepisać na C++. Nikt nie powiedział że aplikacja musi robić wszystko sama.

Jak będzie mowa o statycznych atrybutach oraz metodach to na pewno wspomnę o self::. Zresztą jak można nie wspomnieć. Co do Twojego komentarza to po raz kolejny przytoczę fragment komentarza o młotku: "Młotkiem można w równym stopniu przybić gwoździa co walnąć się w nim w głowę - kwestia komu go do ręki dasz".

@Przemo, a co jak będzie jak Twoje kontrolery będą i małe i duże ? Będziesz tworzył na nie 2 interfejsy ?

Złożoność rozwiązania <= złożoność problemu. Co do przedobrzenia to po raz N+1 przytoczę nieszczęsny młotek. Ciekawe czy redakcja DI pomoże i pozwoli na dołączanie jej do każdego mojego komentarza :P

@DariuszP: Nie do każdej głupoty są nazwy. Gdyby było inaczej to było by tak jak napisałeś :)

Gdy mowa o wydajności to istnieje złoty środek, po którym optymalizacje programowe nie mają sensu i walka o milisekundy zamiast dokupić do serwera RAM czy lepszy procek jest zwyczajnie bardziej opłacalna. Ale jako programista zapewne sam stosujesz się do KISS. Ja także nie należę do zwolenników usprawniania wszystkiego na siłę i optymalizacji bezsensownych bo to moim zdaniem już sztuka dla sztuki. A przepisywanie potem aplikacji na C++ by szybciej wszystko chodziło, tylko dlatego, że jakiś programista źle całość przemyślał to moim zdaniem błąd na etapie projektowania. W normalnej aplikacji więcej niż kilkadziesiąt obiektów naprawdę rzadko bywa wywoływanych dla obsługi jednego usera w trakcie żądania. Obiekty związane z ACL userem, połączeniem z bazą, kilka z reguły do wyświetlania danych strony i ich działów, menu nie przekroczą zapewne kilkunastu. zwłaszcza patrząc na popularność wzorca Singleton. Kilkaset to już ogromna rozrzutność. Sam piszę aplikacje obsługujące duże ilości userów i rzadko kiedy napisanie zajmuje więcej niż kilkadziesiąt klas, gdzie osobno mam klasy modeli, kontrolerów, widoków i helperów.

Co do self i this to można ich zamienność podać jako ciekawostkę PHP. W językach jakie znam, nie występuje to nigdzie indziej.