Mam prośbę. Czy ktoś mógłby przekonać mnie do programowania obiektowego? OK, jak muszę, to programuję obiektowo, ale strasznie tego nie lubię.

Tak naprawdę, nie znalazłam ani jednego argumentu przemawiającego za tym, że programowanie obiektowe jest LEPSZE.

Dlaczego obiektówka jest lepsza? Wciąż napotykam na opinie, że kod jest prostszy (dla człowieka), że bardziej elastyczny, że uporządkowany. Problem w tym, że ja tego nie widzę. Dlaczego jest prostszy? Jeśli mam plik z funkcjami, to sobie po prostu znajduję funkcję i edytuję. Nie muszę się grzebać w tych wszystkich klasach, szukać, skąd i co dziedziczy i co jest do czego. Co w tym elastycznego? Gdzie tu porządek?

Dziedziczenie? OK, to jest jakiś plus, ale raczej pod kątem ilości kodu, ale nie jego zrozumienia.

Jestem ze starej szkoły. Jak pewnie wielu z Was, moje początki były związane z językiem Quick Basic, Pascal, itp... Może, gdybym zaczynała od razu od podejścia obiektowego, łatwiej byłoby mi to zrozumieć.

Pomoże ktoś?

4 podstawowe założenia programowania obiektowego Trochę powinno rozjaśnić przewagę. Jeżeli się według nich nie postępuje (tak jak np często ja) to szybko znajduje się na podsumowaniu "programowanie obiektowe jest zbędne". Pamiętajmy też o tym, żeby nie pchać na siłę OOP tam gdzie jest ono nie potrzebne.

Kluczem do przekonania jest pełne zrozumienie programowania obiektowego.

Powiedzmy, że programowanie obiektowe jest wyższym poziomem programowania, świadomością programisty. Ktoś starszy od Ciebie, ze starszej szkoły powie Ci, że po co będzie pisał w PHP jak może to zrobić w kodzie maszynowym, przecież PHP ma jakieś koszmarne zarządzanie pamięcią.

Tak na prawdę to ja też kiedyś tak myślałem, 2 letnie doświadczenie zawodowe to zmieniło we mnie.

Znasz takie coś jak wzorce projektowe? MVC czy singleton?
Jak rozwiązujesz problem z uprawnieniami użytkowników? w obiektówce masz magiczne metody np __call()
Webservices piszesz strukturalnie? tu masz SoapClient / SoapServer
Dostęp do bazy danych tylko zapytaniem? obiektowo łatwo dostaniesz się do każdego rekordu, nawet możesz ustawić relację (ORM)
Nie dostrzegasz plusów w pracy zespołowej mając system obiektowy?
Jak załatwiasz problem z dostępem do funkcji? W obiektówce masz autoładowanie

Wg mnie nie chodzi o obiektówkę (którą ja sam olewam często i robię np. publiczne właściwości, bo tak mi wygodnie) a o:
- wzorce projektowe. Nie tylko MVC (o którym wszyscy wiedzą) czy singletony (które są mocno krytykowane) ale np. wzorzec obserwatora, odwrócenie kontroli, adapter, fasada itp. A wzorce obiektowe warto poznać, żeby być lepszym programistą (chociaż niekoniecznie trzeba wszystkich używać na siłę, bo to też błąd).

- decoupling ( bardzo ważne!!!!!!!!!!!!!!!!!!!!!!!!!!!!! niestety pisząc obiektowo można zapomnieć o decouplingu, a to sprawia, że psu na budę taka obiektówka, w zasadzie do wyrzucenia). Czyli uniezależnienie obiektów od innych obiektów, jednych klas od drugich, jednego modułu od drugiego modułu, jednej funkcji od drugiej funkcji. Dobrze zaprojektowany kod obiektowy powinien składać się z klocków, które można bez problemu wymienić na inne. Klasy i obiekty nie powinny być zbytnio sprzężone ze sobą (są wzorce projektowe które pomagają to osiągnąć).

- pragmatyzm - w niektórych podejściach klasyczne OOP się nie sprawdza, np. do małego projektu być może nie ma co się babrać w robienie klas, tylko walnąć parę funkcji, parę tablic i pojechać, bo tak będzie po prostu szybciej. Czasem też może być lepszy Data Driven Design, albo programowanie funkcyjne, które przeżywa ostatnio renesans. Obiektówka nie jest już taka cool jak jeszcze parę lat temu...

- ponowne wykorzystanie kodu (ale tutaj obiektówka nie ma nic do rzeczy. kod może być "obiektowy" a nie nadawać się do ponownego wykorzystania, a kod strukturalny może być dobrze zaprojektowany i służyć przez całe lata. Kwestia designu a nie tego czy ktoś napisze sobie słowo kluczowe "class"). Zresztą moim zdaniem istota programowania obiektowego to wcale nie klasy tylko zasada SOLID
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

Ja też jestem ze "starej szkoły" (zaczynałem od ASM na 8 bitowcach ) jednak plusy programowania obiektowego trudno pominąć. Najłatwiej o przydatności dobrze zaprojektowanych klas przekonać się pracując nad dużym projektem. W małych skryptach typu księga gości itp. różnica jest nie zauważalna bo to w zasadzie tylko kilka akcji.

Każdy programista poda Ci swoje, za i przeciw. U mnie z programowaniem obiektowym zaczęło się od Javy nie od PHP a jak wiadomo w Javie wszystko jest obiektem, więc nie dało się uniknąć poznania nowych zasad, co to klasa, metoda, dziedziczenie, interfejs itd. Jak już to opanujesz zrozumiesz do czego to jest to można dojść do wniosku, że programowanie obiektowe stara się uczynić program bardziej intuicyjnym i prostszym do zrozumienia (nasz mózg w sposób intuicyjny potrafi zrozumieć podejście obiektowe). I właściwie to jest kwintesencją OOP, nie jest to żadne podejście które umożliwia nowe rzeczy wszystko co da się zrobić obiektowo da się zrobić też bez użycia obiektów. OOP nie ma też wpływu na bezpieczeństwo naszej aplikacji. Źle zaprojektowane obiekty, są tak samo niebezpieczne jak źle zaprojektowane funkcje / procedury.

Niestety, podczas x lat pracy z językami nie obiektowymi programiście na początku bardzo ciężko przestawić się na myślenie obiektowe (chyba, że tylko ja tak miałem) w kontekście aplikacji, kiedy już przez to przebrniesz zrozumiesz że szybciej i łatwiej pisać obiektowo.

Reasumując, chcąc się rozwijać jako programista, jesteś zmuszona do nadążania za językiem w którym głównie pracujesz. PHP rozwija się obiektowo, tak więc prędzej czy później będziesz musiała się tego nauczyć i postarać się to zrozumieć.

Pewnie się powtórzę ale trudno tak czy inaczej po wielu nieprzespanych nocach z obiektami w końcu któregoś dnia powiesz sobie że jednak warto było.

Doktor pieniążek przekonuje najskuteczniej
Wszystkie oferty pracy jako warunki niezbędne stawiają MVC, programowanie obiektowe i framework....

Odnośnie meritum
Masz rację. W przypadku witryn internetowych często widać przerost formy nad treścią i programowanie obiektowe wpisuje się w ten tręd. Nie jedyny zresztą, że wspomnę o jquery, które mnie osobiście doprowadza do szewskiej pasji. Wpisywanie jako parametru funkcji anonimowej kompletnej funkcji anonimowej, będącej parametrem innej funkcji anonimowej jest chore. Pomimo to padają argumenty o czytelności kodu, oszczędności miejsca itp.

W przypadku dużych projektów pisanych przez wiele osób podejście obiektowe ma jednak olbrzymie zalety.

dołączę się.

Ja raczej nie jestem ze starej szkoły, ale trochę czasu już bawię się w php - 2 lata. Nieraz miałem ataki chęci na napisanie czegoś obiektowo i po max godzinie prób i błędów zniechęcam się na kolejne x czasu. Sam dla siebie piszę teraz duży projekt. Jest w pełni preceduralny, ale pisze go tak, żeby był jak najlepiej poukładany i prosty do edycji. Niemalże wszystko składa się z dobrze napisanych funkcji i wcale nie ma ich tak wiele a strona jest dosyć skomplikowana. Też nie mogę przekonać się co do tego, żeby pisać obiektowo... Niekiedy jak analizuje sobie jakieś klasy zastanawiam się jaki to ma sens ? skoro proceduralnie można zrobić to samo w funkcjach i o wiele krócej. Oczywiście naczytałem się teorii programowania obiektowego i rozumiem jego zalety i sens, ale po za aspektem finansowym - jak to napisał kolega wyżej wszędzie teraz wymagają oop i mvc, nie dostrzegam innej motywacji. Jak narazie nie ma rzeczy, której nie zrobiłbym proceduralnie. Powiem więcej ! wcale nie jest tak trudno napisać poprawny i łatwy do edycji kod nawet do większych projektów.

Najgorsze w oop jest jeszcze to, że nie ma go kto mnie nauczyć ;/ Nie chce wyrabiać złych nawyków i polegać na kodzie, który sam do końca nie wiem czy jest poprawny... Wiem, ze są książki, artykuły itd... ale to nie to samo... Z chęcią poszedłbym na jakiś staż młodszego programisty i pouczył się od innych, ale troche mi daleko do najbliższej takiej firmy.

chyba, że ktoś z was ma złoty środek ?

EDIT:
mam jeszcze jedno pytanie. Nie śledzę aż na tyle tematu ale ktoś z was może się orientuje. To że php dąży do pełnej obiektywności oznacza, że za jakiś X czas w php nie będzie obsługiwane programowanie strukturalne ? jak to w końcu jest z tym mysql_query ? ponoć ma przestać być obsługiwane... czyli za jakiś czas moje skrypty mogą pójść do kosza?

myślę, że nie o to chodzi, żeby się zamykać na obiektówkę, bo to by była ignorancja/noobizm, tylko raczej żeby nie stawiać na piedestale OOP i nie myśleć, że obiektowe programowanie zawsze i wszędzie jest najlepsze, i że całkowicie wystarcza. Czasami warto mieszać paradygmaty, ja np. programując w takich językach jak JavaScript czy Python, programuję niby obiektowo, ale często poszczególne fragmenty piszę w paradygmacie funkcyjnym (nie mylić z proceduralnym!).


a wzorce projektowe? Zrozumienie tego, kiedy warto użyć jakiś wzorzec projektowy, a kiedy inny w sumie może oszczędzić dużo zachodu przy programowaniu - bo nie musisz za każdym razem wymyślać koła na nowo tylko od razu myślisz "o, podzielę kod na Model, Widok i Kontroler, a tu użyję obserwatora". Co prawda żeby użyć MVC nawet obiektówka nie jest potrzebna - ale mimo wszystko jak się czyta coś o wzorcach projektowych to wszystkie przykłady są na OOP, więc i tak łatwiej zrozumieć i zaimplementować w OOP.


a jakbyś chciał ten projekt podzielić na dwa mniejsze? nie wiem co piszesz, ale załóżmy że jakbyś pisał CMSa, na którym masz
- edycję i dodawania artykułów
- możliwość wysyłania wiadomości prywatnych
- panel do logowania
- forum
itp.
to czy jakbyś np. chciał zrobić drugi projekt, całkiem inny, ale np. chciałbyś, żeby w tym drugim projekcie była możliwość logowania i wysyłania wiadomości prywatnych -- to czy mógłbyś bez problemu bazując na kodzie pierwszego projektu, wydzielić kod odpowiedzialny za logowanie i wysyłanie PW -- a potem zaimportować go do drugiego projektu?

Chodzi mi o to, czy piszesz w sposób modularny - bo jeśli tak, to pewnie nie ma problemu.
Gorzej jak każdy projekt jest jednolitą masą - teoretycznie obiektówka ma temu zapobiegać, bo się dzieli kod na obiekty - ale w praktyce i tak może się zdarzyć, że kod obiektowy również będzie jednolitą masą splątanych ze sobą obiektów, których nie będzie się dało wyjąć z danej aplikacji. Wtedy byś tego kodu nie mógł łatwo wyciągnąć i nie mógłbyś go łatwo użyć w kolejnym projekcie.

@PrinceOfPersia

Dzięki za odpowiedź : ) każde zdanie w tej kwestii jest dla mnie przydatne.
Projekt, który robię będzie komercyjnym portalem - pomysłu nie zdradzę ; ) Piszę go na spokojnie i każdy nowy element najpierw mocno analizuje i szukam najlepszego rozwiązania- po czym przechodzę do kodowania. Od tego projektu również stosuje model MVC. Nie wiem czy wypada się tym chwalić - bo jak napisałes wszędzie jest ten model przedstawiany w oparciu o OOP, ale dla mnie jak najbardziej zdaje egzamin pisząc strukturalnie. Nie chce wprowadzać do tego projektu obiektówki, bo nie chce aby w tym projekcie był kod, który nie jest pewny i może bardziej szkodzić niż służyć. Jedyne co mnie gryzie to PDO - z chęcia bym u siebie to zastosował, no ale z drugiej strony wszystko mam już dobrze zabezpieczone (całkowicie wyeliminowane sql_inj xss csrf i inne syfy).

przemyślałem teraz tą kwestie i szczerze powiem, ze bez problemu. Od tego właśnie mam funkcje. Uważam na to aby nie uzależniać jednej funkcji od drugiej. Oczywiście niektóre mechanizmy tego wymagają, np hashowanie/sprawdzenie sesji i ciastka, ale to również działa jako ala moduł i mogę to bez problemu zastować gdzie indziej.
Wydaje mi się, że kazdy projekt wymaga osobnego podejścia, dlatego też zawsze coś trzeba będzie dopasować ze starego kodu - grunt to zrobić to tak aby było tego jak najmniej.
Tak czy siak wiem, że skoro bawie sie w php, to nie wypadałoby nie poznać oop i choć droga ku temu będzie ciemna i kręta to zła się nie ulęknę ; )
A doczepiłem sie do tematu dlatego, że wszędzie gdzie się nie czyta o zaletach i wadach obu tych "stylów", to w zdecydowanej większość pisze, że nie da rady napisać coś większego strukturalnie. Z czego to wynika ? Mi osobiście się wydaje ze z niechlujstwa i niewiedzy. Tak jak napisałeś, obiektowo tez można spartolić robotę - tak samo strukturalnie, ale za pomocą jednego i drugiego można zrobić co tylko się chce i to na cacy.

ps: jakbym teraz zaprezenotwał Tobie mój kod to gwarantuje Ci, że bez problemu ogarnąłbyś wszystko co się w nim dzieje. Nikiedy jak przeglądam jakieś klasy w oop, to również odnoszę wrażenie - podobnie jak @paramyksowiroza, że ciężej jest poznać ich logikę. Nawet jak wracam do starszych projektów to nie mam problemu z odczytaniem teog jak działa dana funkcja iz ajmuje mi to moment. Mimo iż oop jest ponoć stworzone na wzór ludzkiego rozumowania, to jednak niekiedy trudno jest mi ogarnąć całą droge jaką przebywa obiekt w jakiejś klasie. Napewno to kwestia mojego braku praktyki, no ale dobra, nie będę ciągnął tego w nieskończoność ; ) niech Bóg da mi siły na ogarnięcie oop !

ja jestem co prawda za obiektówką, bo jest wygodna i odpowiada mniej więcej temu, jak ja widzę kod (chociaż nie stawiam obiektówki na piedestale, bo to tylko jeden z paradygmatów programowania,), ale przecież masę naprawdę wielkich projektów powstało właśnie w strukturalnie, w języku C, który nawet nie wspiera OOP (chociaż można to emulować). W C można nawet system operacyjny napisać, mimo że nie ma tam żadnych obiektów.

Więc da się.
Chociaż ja podchodzę do tego w ten sposób, że warto poznać praktycznie jak najwięcej paradygmatów i wzorców, żeby wiedzieć, które się najlepiej sprawdzają do danej rzeczy.


ludzie przesadzają z klasami, właściwościami, metodami. Np. są tacy, którzy do każdej zmiennej prywatnej robią getter i setter, np. getZmienna, setZmienna, getDrugaZmienna, setDrugaZmienna, co już samo w sobie jest złamaniem OOP (bo robienie getterów i setterów do zmiennych, które powinny pozostać prywatne to łamanie zasady enkapsulacj/ukrywania danych).

Przesadza się też z hierarchią i dziedziczeniem, co niestety też zaciemnia kod, jeśli masz 10 stopni hierarchii klas potomnych.

Odpowiedź jest prosta: nie rozumiesz lub nie używasz programowania obiektowego - jesteś jeszcze uczniem nie programistą.
Oprócz logistyki kodu, wzorców projektowych itp. nie da się wielu sztuczek programistycznych osiągnąć na samych funkcjach.
Po prostu nie można zabronić przed używaniem niektórych funkcji, zastosować polimorfizmu, czy choćby
używać frameworków MVC bez OOP i koniec.
Tak samo jak nie da się z Seicenta zrobić samochodu ciężarowego.
Legitymowanie się jako programista PHP nie znający obiektowości na pewno nie odbije się pozytywnie na twojej pozycji na rynku pracy.
Jedyna droga, to wydać trochę forsy na dobre książki (w Helionie jest ich z 50 na ten temat) i przysiąść kilka dni nad tematem.

@paramyksowiroza
http://forum.php.pl/index.php?showtopic=205797

polimorfizm da się osiągnąć nawet w C (bez użycia klas, emulując obiektówkę za pomocą struktur i wskaźników na funkcje), w PHP można by było zamiast obiektów używać tablic asocjacyjnych i anonimowych funkcji:

[PHP] pobierz, plaintext 
$Pracownik = ['pracuj'=>function() {echo 'pracuje.';}, 'wyplata'=>3500];
 
// definicja "klasy" Dyrektor:
$Dyrektor = $Pracownik; // class Dyrektor extends Pracownik....
$Dyrektor['pracuj'] = function($this) {
   echo "nic nie robie, bo jestem dyrektorem, zarabiam $this[wyplata]zl<br>";
};
$Dyrektor['wyplata'] = 10000;
 
// definicja "klasy" Sprzataczka:
$Sprzataczka = $Pracownik; // class Sprzataczka extends Pracownik....
$Sprzataczka['pracuj'] = function($this) {
   echo "sprzatam, zamiatam, zarabiam $this[wyplata]zl<br>";
};
$Sprzataczka['wyplata'] = 1600;
 
 
function wywolajMetode($obiekt, $metoda) {
	$obiekt[$metoda]($obiekt);
}
 
 
$dyrektor = $Dyrektor; // cos jak: $dyrektor = new Dyrektor()
$sprzataczka = $Sprzataczka; // cos jak: $sprzataczka = new Sprzataczka()
 
 
wywolajMetode($dyrektor, 'pracuj');
wywolajMetode($sprzataczka, 'pracuj');
[PHP] pobierz, plaintext 

i mamy polimorfizm oraz hierarchię obiektów na tablicach asocjacyjnych.
pytanie tylko PO CO skoro są klasy?
ale wrzucam po prostu jako proof of concept, że polimorfizm da się osiągnąć na samych tablicach asocjacyjnych i funkcjach anonimowych.

Tworzyłem spore systemy wtedy, gdy OOP nie było jeszcze tak popularne. Zacząłem je tworzyć, gdy do OOP nie było żadnych sensownych narzędzi. Nikt by mnie nigdy nie przekonał do przerzucenia się na OOP. Zmusiły mnie do tego biblioteki, czy też jak to się dziś już mówi frameworki wymuszające OOP. Także proponuję autorowi, aby przerzucił się na jakiś MVC FW, a po roku będzie się dziwił, że tworzył kiedyś inaczej.

Nie wiem gdzie tu widzisz polimorfizm, tym bardziej jakąkolwiek hierarchię, chyba, że opierasz domniemaną hierarchię na sytuacji zawodowej typu dyrektor/sprzątaczka.
Kod prezentuje po prostu to co się znajduje w tablicy pod wskazanym indeksem.
Jak spróbujesz dowiedzieć się ile zarabia ktoś, kogo w tablicy nie ma, np. kierowca, otrzymasz błąd pehapa

no, zarówno Sprzataczka jak i Dyrektor "dziedziczą" z Pracownika. To znaczy:
1. tworzymy tablicę $Pracownik

2. a potem kopiujemy tę tablicę $Dyrektor = $Pracownik, i mamy dziedziczenie prototypowe (powszechnie stosowane w JavaScripcie, w PHP oczywiście inaczej się to robi zwykle, bo są klasy - tym niemniej, też się tak da pod kątem czysto technicznym - tak samo jak w JavaScript da się technicznie emulować klasy).

3. zarówno Dyrektor jak i Sprzataczka dziedzicza właściwości po Pracowniku, więc mają defaultowo 3500zł pensji i defaultową "metodę" pracuj.

4. dlatego ustalamy indywidualną pensję:
$Dyrektor['wyplata'] = 10000;
oraz własną metodę pracuj
$Dyrektor['pracuj'] = function($this) {
echo "nic nie robie, bo jestem dyrektorem, zarabiam $this[wyplata]zl<br>";
};

DISCLAIMER: cały kod to oczywiście tylko "proof of concept" (który stał się możliwy dzięki wprowadzeniu funkcji anonimowych do PHP).



jest przecież metoda o tej samej nazwie "pracuj", natomiast co innego robi, $sprzataczka inaczej pracuje, inaczej pracuje $dyrektor.


nikogo nie ma w tablicy, bo nie na tym to polega. Nie zrobiłem żadnej tablicy z pracownikami, jeśli tak ci się wydaje, to niezbyt uważnie przeczytałeś ten kod.
Tablice asocjacyjne są tutaj zamiennikami klas i obiektów.
zamiast $pracownik->pensja, mamy $pracownik['pensja']
zamiast $pracownik->pracuj();, mamy $pracownik['pracuj']($this);

gdy tylko pojmiesz OOP, to je pokochasz całym sercem. OOP nie skupia się na pisaniu kodu, tylko na jego wykorzystywaniu.

Tak naprawdę OOP to poszerzenie horyzontów. Tu nie chodzi o to jak masz pisać funkcje - tu chodzi o możliwości oraganizacji, manipulacji oraz wykorzystywania kodu, z których nie zdajesz sobie sprawy. OOP to idea jak dzielić kod na bloki (obiekty), które później mają się ze sobą komunikować i ułatwiać wykonywanie wszelkich potrzebnych nam zadań. W tej chwili tkwisz w świecie który znasz i nie widzisz sensu w OOP, ale tylko dlatego, że tak naprawdę nie masz zielonego pojęcia co idzie za OOP.

Wyobraź siebie w tej sytuacji - jesteś na Syberii, żyjesz z dnia na dzień, jest Ci dobrze, przyzwyczaiłeś się do tego życia. Dajesz sobie radę... ktoś powiedział Ci, że "gdzieś tam" jest lepszy świat, słyszysz o tych wyspach, o plażach, koktajlach, kobietach w bikini i nie dowierzasz. Wiesz, że tam musiałbyś rozpocząć całkowicie nowe życie, musiałbyś zapoznać się z nieznanym. To Cię odstrasza - nieznane oraz niezrozumiane. ; )

Musisz po prostu zrozumieć ideę. Programowanie obiektowe to idea, gdy ją zrozumiesz, wtedy będziesz mógł ją wykorzystać w każdym języku, który wspiera OOP. OOP nie oduczy Cię tego, co teraz umiesz. OOP nauczy Cię jak LEPIEJ wykorzystać to, co już umiesz.

Jeśli nie chcesz poszerzać horyzontów i rozwijać się, wtedy możesz z powodzeniem pisać aplikacje tak jak pisałeś do końca swoich dni - nikt Ci tego nie będzie miał za złe, naprawdę. To Twoje życie, rób co chcesz. Ale jeśli chciałbyś zabrać się za sensowniejsze praktyki w programowaniu, wtedy OOP czeka na Ciebie z otwartymi ramionami - kup sobie jakąś książkę, zrób kilka przykładów - jak załapiesz o co chodzi, to już Cię od OOP nikt nie odciągnie, bo to po prostu daje większe możliwości.

@up

pięknie <3

No OK
Specjalnie zahaczyłem bo ciekawiły mnie dogłębniejsze wyjaśnienia
Przyznaję rację, że coś w tym jest

Napisany klasy można wykorzystać w innych projektach. Zmniejsza konieczność powtarzania kodu w aplikacji. Serwis napisany obiektowo jest z reguły łatwiejszy w rozbudowie i modernizacji. Na początku projektowanie obiektowe może wydawać się trudne i niewygodne, jednak z czasem praktycznie każdy programista dostrzega jego zalety.