Mam taką propozycję, aby ktoś kompetentny (nie ja...) napisał artykuł o podstawowych różnicach między obiektowym i strukturalnym (proceduralnym, liniowym - ile jeszcze określeń?) PHP.

Dlaczego? Dwa razy czytałem książkę o OOP... Jedynie pobieżnie czytałem podrozdział o różnicach pomiędzy tymi dwoma światami. A różnice są i jeżeli np. (tak jak ja, ale dzięki odpowiedzi mike'a w tym wątku zacząłem czytać książkę po raz 3ci i...) uważasz, że programowanie obiektowe to takie w którym jedynie używasz klas, obiektów, narzędzi i przeplatasz to z liniowym php - to jesteś w błędzie. Pewien jestem, że przyda się to każdemu samoukowi.

Edit: Żeby jakaś mądra głowa nie wpadła na pomysł "że jest to oczywiste" - nie nie jest to oczywiste, może zapomnieliście już te czasy, że nawyk ze struktur przenikał wasze kody od szpiku... Ale ja nie i dlatego chcę pomóc mnie podobnym, którzy "jeżdżąc dieslem - myślą że olej silnikowy jest nie potrzebny". Około 19:00 dopiszę "punkty" jakie moim zdaniem powinny znaleźć się w takim artykule, bo fakt "mądre głowy" nie do końca mogą wiedzieć o co mi chodzi. Peace Y

Napisz coś więcej, ale moim skromnym zdaniem musisz zwyczajnie zrozumieć, że OOP to sposób myślenia o kodzie. Fizycznie różnice w kodzie są wtórne, kod jest wtórny względem paradygmatu obiektowego i trudno w jakiś sensowny sposób przedstawić drogę od wniosków do przesłanek, po lekturze której załapiesz w czym rzecz. To po prostu wymaga paru nieprzespanych nocy i dużej wyobraźni. Skup się na takich pojęciach jak zadanie, podmiot oraz na relacjach między nimi w języku naturalnym
"Basiu kup golonkę", "Wojtku, weź różową kredkę i narysuj samolot" itd. Podkreślaj podmioty i rzeczowniki, bo to są najczęściej obiekty. Czasowniki to operacje, a przymiotniki odpowiadają za właściwości (składowe/zmienne obiektu). Jak tak parę bardziej złożonych zdań przekujesz na kod, to zrozumienie samo przyjdzie.

ii ja mam to zrozumieć ?

Pomimo tej odrobiny sarkazmu jestem szczerze zaszczycony i biorę określenie "mądra głowa" bardzo do siebie, bo podobnie jak inni bladego pojęcia nie mam o co ci chodzi. Oczywiście istnieje też taka możliwość, że jestem kompletnym kretynem, ale staram się zawsze myśleć pozytywnie.

Z niecierpliwością wyczekuję 19stej.

Jak obiecałem tak piszę.

Głównie chodzi mi o wykorzystanie (nie każdy samouk czyta książki) podrozdziału "Programowanie obiektowe i proceduralne" z PHP5 Obiekty, wzorce, narzędzia.



Są jednak kluczowe różnice pomiędzy dwoma kodami. Moją propozycją jest aby w artykule porównać (tak jak w książce) dwa kody robiące "to samo" oraz wyszczególnić wspomniane różnice:
Podział odpowiedzialności: dla kod porceduralny to sekwencje poleceń, które nie raz są powielane (chociażby sprawdzanie czy zmienna x jest stringiem). W kodzie obiektowym natomiast następuje próba minimalizacji tych zależności i zepchnięcie pewnego zadania na dany obiekt istniejący w systemie, przez co kod nie jest powielany.
Spójność i sprzęganie: w proceduralnym kodzie nasze funkcje, klasy - nawet jeżeli są w jakiś sposób powiązane często wędrują po naszym kodzie. Często trzeba zmieniać kilka funkcji, klas, bo części kodu są od siebie tak zależne, że przy zmianie jednej funkcji musimy zmieniać kolejną... W obiektowym zaś - klasa często niejako spaja kilka metod w jednym miejscu - a jeżeli wiele metod z różnych klas robi "to samo" - to mamy już do czynienia z rozluźnieniem i należy przeanalizować kod. W kodzie obiektowym konserwacja jest zminimalizowana. Za zwyczaj zmienia się jedną klasę, metodę i dodaje kolejną klasę, która ma być odpowiedzialna za jakieś zadanie.
Ortogonalność: promuje łatwość wykorzystania istniejących już komponentów (co praktycznie nie istnieje dla programowania zorientowanego proceduralnie) przez włączanie ich do nowych systemów bez konieczności ich przystosowywania w sposób spartański.
Nie ma automatycznego narzędzia mierzącego spójność, sprzęganie czy ortogonalność - musimy użyć mózgu .

Kolejnymi "ważnymi regułami" są: zasięg klas, polimorfizm (trudne słowo ) i hermetyzacja (kolejne trudne słowo ).

Kolejnym "punktem" w artykule moim zdaniem powinien być "dekalog", według którego należy projektować i pisać nasz kod. Dekalog to za mocne słowo, ale coś w stylu dobrych rad jak np.:


Jak Cysiaczek napisał: "OOP to sposób myślenia o kodzie." - i to jest prawda. Ale gdzie leży ta "granica"?

Ok lecę na zakupy - bo mnie kobieta goni . Ręczniki trzeba kupić :/

Nikt nie powiedział, że w kodzie proceduralnym nie można napisać funkcji.


Nikt nie powiedział, że w kodzie proceduralnym nie można pisać uniwersalne funkcji (przyjmujących parametry i dzięki temu działające dla każdego przypadku)

Ogólnie brniesz chyba w złą stronę skupiając się za bardzo za fizycznych różnicach obu podejść. Obiektówka różni się sposobem myślenia i formułowania kodu czyli bardziej mentalną sprawą. Przejście między tymi dwoma sposobami kodowania nie następuje w dzień, dwa czy tydzień, jest to proces dłuższy więc się nie przejmuj jeśli nie do końca wszystko na początku rozumiesz.
Jeśli dopiero zaczynasz to na pewno pomocnym będzie to co napisał Cysiaczek o golarce i różowych kredkach. Jeśli projektowałeś kiedyś bazę to także jest pomocne bo większość tabel to właśnie obiekty. Np. mamy aplikacje do urządrzania pokoju, tabelki

user | item | user_has_item

obiektowo:

[PHP] pobierz, plaintext 
$u = new User('luq');
$i = new Item('safka');
$i->setColor('#f00');
$u->addItem($i);
[PHP] pobierz, plaintext 

Naprawdę taki artykuł o którym piszesz jest zbędny

Nie myśl w sposób obiektowy o kodzie proceduralnym. Mając 2 funkcje w obu napiszesz sprawdzanie np. czy zmienna x jest stringiem, myśląc obiektowo (tak pewnie pomyślałeś) napisałbyś inną funkcję która sprawdza to czy zmienna x jest stringiem... Ale proceduralne myślenie nie utworzy kolejnej funkcji... Rozumiesz o co chodzi?


Przemądrzała funkcja? I to ma być myślenie obiektowe? I przenieś tą funkcję do innego projektu...


Sam skupiasz się na MNIE, a nie na problemie. Świat jest materialny i dlatego skupiam się na tym co jest fizyczne .

#luq rozumiem, że chcesz mi pomóc - na pewno przemyślę to co napisałeś do mnie. Ps. Fajny blog, ciekawe rzeczy.

Sam bym ten artykuł napisał, wstawił na swojego bloga (jak na razie jest pusty ), problem w tym, że nie jestem na tyle dobrze obyty w filozofii tworzenia kodu w sposób obiektowy. Pewnie gdy już będę - zapomnę co chcę powiedzieć "teraz".

Panowie. Rozumiem, że dla was jest to oczywiste, ja dopiero zaczynam łapać i jasno widzę te różnice - dlatego nie staram się być jak ten "profesor" z kawału:
"Co to jest student? Student jest jak liść dryfujący po wielkim morzu w stronę wysepki, aby w końcu odpocząć.
A co to jest profesor? Profesor to koleś na tej wysepce robiący fale - aby liście nie mogły dopłynąć do wysepki.
A co to są liście na wysepce? To ludzie, którzy mogliby pomóc, ale zapomnieli już jak to jest podczas dryfowania."

Fakt, "mądre głowy" (nie ma tu złośliwości - jak starach napisał - komplement) nie zainteresują się takim artykułem bo uważają, że jest taki artykuł zbędny. Chodzi o przypomnienie "drogowskazów" dla nich, a pokazanie poprawnej ścieżki dla "mnie podobnym" . Zerknijcie pobieżnie na wątki w oop - używanie zmiennych globalnych czy wszechmocne klasy - to nie jest obiektowe programowanie. Zła filozofia, coś pomiędzy. Ja, mnie podobni + pewnie niektórzy uważający siebie za expertów oop właśnie na takim etapie są. Robiąc głupie błędy w myśleniu.
U mnie myślę jest ok - wiem, że przestawienie się nie zajmie dnia, skoro w proceduralnym robiłem wcześniej magię .

Kolejnym faktem jest to, że początkujący raczej nie zaglądają do artykułów :/ co znowu przemawia na niekorzyść. Także walczę z wiatrakami.

Wiesz to nie jest tak, że po przeczytaniu 500 książek oraz artykułów i napisaniu 500 klas człowiek staje się alfą i omegą wiedzącą gdzie co jak i kiedy zastosować. Najlepszą nauką po zapoznaniu się z teorią jest przejrzenie kodu już napisanego. Jednak nawet w takich frameworkach jak Zend, Symfony czy Kohana znaleźć można rozwiązania i konstrukcje które potrafią zadziwić.

Cały problem polega na tym, że zasady obiektowe są w miarę elastyczne. To jest trochę tak jak z wcięciami w kodzie. Jeden woli na 1 tab = 4 spacje inny 1 tab = 2 spacje i jeszcze inny woli spacje nie zamieniające się w tab. Zresztą gdzieś na forum jest jedna dyskusja o stosowaniu metod magicznych która o mały włos nie zamieniła się w Dżihad.

Jak znajdziesz już metodykę, którą będziesz sukcesywnie stosować opisz ją gdzieś. Chętnie przeczytam, a może nawet trochę podyskutuję o gustach.

Co do alfy i omegi - co racja, to racja... Myślałem, że wiem "coś" - a niedawno myślałem dobrą godzinę nad zapisem

[PHP] pobierz, plaintext 
if ($foo = $this->fooBar($bar))
[PHP] pobierz, plaintext 

, a to takie oczywiste, że aż mnie zagięło :/.

Jeszcze kupę kodu przede mną . A na razie nasza dyskusja byłaby porównywalna z rozmową studenta i przedszkolaka (gdzie ja to ten 2gi ). Choć "każdy głupiec ma czasem coś mądrego do powiedzenia".

Ps. ten wątek chyba bardziej pasuje do hydeparku...

ixpack, mam wrażenie że za dużo czytasz, a za mało robisz . Oczywiście solidne podstawy się przydadzą, ale nic nie zastąpi ładnych paru tysięcy linijek napisanego kodu. Praktyka ma to do siebie, że potrafi być bardzo skutecznym nauczycielem. Uważam, iż toczenie stricte akademickich dyskusji nie nauczy Cię myślenia w sposób obiektowy. Napisz jakiś moduł i wrzuć go do oceny, a na pewno dostaniesz mnóstwo cennych wskazówek. Wtedy będzie sporo miejsca na sensowną polemikę, która zdecydowanie bardziej Ci się przyda.

Obawiam się, że zaproponowany temat artykułu, będzie kolejnym z serii już istniejących .

~"PHP, Apache, Mysql od Podstaw"~ nie pamiętam do końca tytułu, bo dawno czytałem, wyd. Helion.
Na allegro można kupić jeszcze chyba