Siemka
Może tak trochę nie na temat, ale zaczynam się zagłębiać w obiektowe i mam jedno podstawowe pytanie: po co wgl to programowanie obiektowe?

Nie łatwiej operować na proceduralnym?
Napisać kilka funkcji w jednym pliku i wyjdzie na to samo.

Czy może ktoś mnie oświecić?
W php nie widzę właściwie różnicy w samej taktyce pisania między funkcjami a klasami. Poza dziedziczeniem, ale nie widzę sensu. Dobry programista potrzebuje obiektowego? Jeżeli tak to po co?. Po co utrudniać sobie tak życie?

Fan WP?

http://www.felixgers.de/teaching/oop/oop_intro.html

Masz klasy. Klasy mają swoje zadanie. Klasy mają metody odpowiedzialne za cząstkowe zadania Obiektu.
Rozdzielenie różnych zadań do poszczególnych obiektów daje uporządkowany system.

Kod nie wala się w plikach setkami linijek nie znając swojego początku.
Mam "przyjemność" pracowania nad jednym sklepem pisanym funkcyjnie i szlak mnie trafia jak widzę kolejny include dołączający coś gdzieś.
Nie wiadomo co gdzie jest, co skąd wychodzi, jakie ma zadanie. Kod jest chaosem.

Dalej pisał nie będę bo można tak godzinami.

Tak. Masz rację.
Jednak dobrze napisany kod ma include do podstawowych funkcji wtedy łatwiej czytać kod.

Za to klasy mają autoload… A odpowiednia struktura katalogów (np PSR-4) również poprawia czytelność kodu.

Kilka funkcji w jednym pliku? Dla przykładu w jednym projekcie jesteśmy na etapie MVP i mamy bagatela 8k LLOC, 270 klas i prawie 900 metod. Powiedzmy, że mamy gotowe jakieś 10% całości. I mówimy o samym kodzie PHP :) I do tego jedyne 1000 testów jednostkowych. Trudno mi sobie wyobrazić przepisanie tego na procedural...

Niestety to nie jest takie proste jak Ci się wydaje. I nie mówię tego dla tego, że uważam, iż OOP jest lepsze niż procedural. C nie jest OOP a jakoś żyje i ma się dobrze.
Wydaje mi się, że chodzi bardziej o klasę aplikacji. Styl proceduralny jest raczej stosowany tam, gdzie skomplikowanie logiki biznesowej jest małe, albo tam, gdzie mówimy o embedded ©. Wtedy rzeczywiści procedural może się lepiej sprawdzić niż OOP.
Ale w miarę rozrostu logiki biznesowej procedural staje się trudniejszy do ogarnięcia (IMO).

PS. Nawet WP nie jest stricte proceduralne :)

Sens jest i to ogromny. Inaczej by tego nie wymyślono i nikt by tak nie programował. Pewnych rzeczy po prostu nie zrobisz strukturalnie.

Wiedźmin 3 strukturalnie: If find potwór: include walka_system & potwór_functions -> If potwór big: licze_obrażenia('anakonda') -> if dostałem: licze_moj_armor('ze skóry niedzwiedzia)
no i miej tu teraz osobne reguły dla każdego potwora , okoliczności, zbroi i innych

Na początku - oczywiście, że jest łatwiej na proceduralnym, ale z czasem wraz ze wzrostem umiejętności i doświadczenia programisty ta różnica się zaciera, nie ma w sumie łatwiejsze / trudniejsze. Jest lepsze / gorsze i już po prostu boli Cię kiedy musisz napisać coś linijka po linijce

Powiem Ci, że miałem kiedyś podobne wątpliwości / pytania co ty:

Po co tego używać w ogóle
po co pchać coś w klasę skoro teoretycznie można to samo wrzucić w funkcje
po co sobie komplikować
i inne tego typu.
Praktycznie wszędzie tam gdzie widziałem klasę, myślałem sobie przecież szybciej będzie jeśli zrobię to proceduralnie.

Wynikało to z tego, że własnie niedokładnie rozumiałem ideę obiektowości, a klas używałem w sumie trochę na wyrost.
Przede wszystkim musisz zmienić myślenie z proceduralnego na obiektowy .
Wiadomo łatwo mówić, ale chyba jedynym sposobem, żeby to się stało jest po prostu programowanie i próbowanie robienia czegoś w OOP. Lepsze zrozumienie przyjdzie Ci z czasem. Musisz dalej ćwiczyć i programować w OOP a programowanie w ten sposób stanie się przyjemne i będzie coraz bardziej logiczne.

Napisanie kilku funkcji w jednym pliku to nie to samo co klasa. Nie możesz traktować klasy jako zbiornika dla różnego rodzaju funkcji (np popularne library.php czy inne functions.inc)
Bo wtedy to faktycznie niczym się to nie różni a dodatkowo trzeba (zazwyczaj) tworzyć instancję i wywoływać funkcje z dodatkowym operatorem i nazwą instancji.
Fakt wtedy to się wydaje zbędne i komplikujące sprawę. I tak to pamiętam właśnie.

Marnujesz wtedy jedynie potencjał jaki daje Ci OOP. Kup se piwo, otwórz, ale nie wypijaj - niech se stoi. Chyba wystarczająco przekonywujące

Klasa to pewnego rodzaju opis problemu, dziedziny (obiektu), którą się zajmujemy, ale w języku programowania.
W klasie opisujesz za pomocą logicznie dobranych metod i pól to co będziesz chciał później zrobić z jej obiektem. Następnie operujesz na tych właściwościach w celu pobrania/zmiany tych danych.
I teoretycznie możesz to robić w dowolnym miejscu dowolną ilość razy.

Samochód masz zielony, 5 osobowy, masz klakson, drzewko zapachowe i szyberdach. Szyberdach możesz otworzyć, drzewko wymienić, kolor może być ładny lub brzydki -> kwestia gustu np dziewczyny, która też jest obiektem , a autem możesz jeździć - jeśli masz prawko. Spoko - w strukturalnym też by tak można było opisać samochód. Ale z takim obiektem możesz zrobić różne rzeczy w poniedziałek, wtorek,... piątek, w Polsce i Niemczech. Czyli gdzie chcesz i kiedy chcesz na różne sposoby.
Służy Ci do czegoś więcej niż tylko do jeżdżenia na zakupy w środę po drzewko bananowe.

W strukturalnym taki samochód byłby smutny ponieważ jeździłby tylko w określone dni na określone kursy Ponieważ tak postanowił zły strukturalny Stary, który pozwala użyć samochodu IF nie wrócisz za późno.

Masz po prostu lepsze wykorzystanie kodu.

(ps .co do powyższego przykładu. Tylko nie mów nigdy dziewczynie, że jest obiektem klasy sexy . Spowoduje to wykonanie metody $pussy->wetControl('getDry') no i return false )

Aby móc coś zrobić z tym obiektem tworzysz jego instancję. Czy to w trakcie dodawania użytkownika czy wybierania rekordu z artykułem, czy zapisu czegoś do bazy -> w zależności do czego masz klasę i co potrzebujesz.
Następnie za pomocą wcześniej zdefiniowanych "rzeczy" operujesz na nim w określony sposób. Do dyspozycji dostajesz konkretne dane, na których możesz robić konkretne rzeczy. A nie gdzieś tam coś tam z d|_|py.

Masz to w klasie MojaKlasaDoCzegośTam w odpowiednim folderze, a nie w linijce 397 zaraz po IF, który sprawdzi coś tam a następnie dokona walidacji czy ciąg nie jest czasem pusty następnie przerobi twój ciąg w taki i taki sposób , żeby potem w linijce 425 wstawić coś do bazy

Dzięki temu kod jest bardziej przejrzysty , wszystko ma swoje miejsce jest logiczne wytłumaczenie i odseparowane. Dodatkowo łatwiej zajmować się rozwiązywaniem problemów i rozwijać aplikację. Aplikacja OOP jest po prostu lepsza*. Obiekty są/mogą być ze sobą ściśle powiązane i współdziałają ze sobą.
Korzystasz z nich w wygodny sposób, a kod masz czytelny.

OOP To wcale nie jest utrudnianie sobie życia, wręcz przeciwnie. Spróbuj sobie wyobrazić dużą aplikacje typu forum gdzie wszystko jest napisane jedno pod drugim i rozbite na ileś tam includów. Weź coś tam przerabiaj - np zmień name dla inputa i zmieniaj wszystko x 20 i to pewnie w kilku plikach. A najpierw to ogarnij..

Mimo iż w proceduralnym również można po kombinacjach wyodrębnić sobie Model Widok i Kontroler to dalej ciężko będzie połapać się w kodzie kiedy wrócisz do niego za kilka miesięcy i zechcesz coś zmienić / ulepszyć / poprawić. (ps. nie twierdzę, że MVC jest "wymogiem/standardem" w OOP)

*Wiadomo, że w przypadku gdy potrzebujesz tylko switch case coś: include coś i ewentualnie wyświetl datę to może być czasem przerost formy nad treścią aby robić to OOP.
Im więcej operacji, zadań, obliczeń, powiązań tym lepiej zacznie się sprawdzać OOP.

Zalety, które z czasem dostrzeżesz:

1. Lepsza organizacja i wykorzystanie kodu
2. Łatwiej i szybciej będziesz ulepszał swoją aplikację
3. dodatkowe mechanizmy takie jak: dziedziczenie, hermetyzacja, polimorfizm, interfejsy, autoload i inne <- które są naprawdę pomocne
4. wygoda
5. raz napisane klasy - skrócenie czasu pracy + wykorzystasz sobie je w przyszłości. A kopiuj tu teraz i wycinaj co potrzeba ze strukturalnego i zmieniaj co trzecią linijkę w zależności od projektu


I co do innego pytania: tak- dobry programista programuję OOP. Co nie znaczy, że jeśli raz na jakiś czas zrobi coś proceduralnie traci lvl

W sumie jak tak to czytam to nie wiem czy wytłumaczyłem Ci sens. Chyba lepiej by było dać jakieś przykłady.. Chodziło mi głównie o to, żeby wykazać Ci przewagę OOP, żebyś to zaakceptował i przyjął do wiadomości. Więc nie porzucaj tego stylu tylko ćwicz ćwicz.

Słowa kluczowe: po prostu, następnie, w sumie,

Ja dla przykładu używam OOP gdy wyniesie korzyści a nie tylko piękniejszy kod.
Dla mnie sie najbardziej przydaje, dla przykładu.
Operacje cURL-em.

funkcjami bym robil cos typu:

send('url','POST');
send('url','POST');
send('url','POST');
send('url','POST');
send('url'); # tu domyslnie get
send('url'); # tu domyslnie get
send('url'); # tu domyslnie get
send('url','POST');
send('url'); # get
Itp.

W klasach mozna to oczywiscie skrocic.

$c->method='POST';
$c->send('url');
$c->send('url');
$c->send('url');
$c->send('url');
$c->method='GET';
$c->send('url');
$c->send('url');
$c->send('url');

Itp może dałem zły przykład ale mi tak się podoba i mam z tego zysk.
przykladowo gdy:

Bot się loguje, potem idzie pod 20 roznych linkow.
Raz zmieniam na post potem get i znow tak.

Lepsze to niz za kazdym razem przypisywac send('url','metoda');
Lub tez tworzenie oddzielnych ((funkcji)) do post, get, itp.
Czy inne duplikacje kodu;

To był tylko przykład.

No i właśnie ćwiczę, tylko ciężko jest coś dobrego znaleźć w necie jako kurs. Logowanie i rejestracja oraz kilka podstawowych spraw, od których zacząłem przygodę z php ładnie opisał Rafał Brzeziński. Niestety w OOP nie mogę znaleźć przykładowego takiego artykułu, który wszędzie się sprawdzi, czyli logowanie, rejestracja, profil, lista userów, edycja danych. Wszędzie tylko teoria, a praktyki prawie w ogóle nie ma.

Spróbuj coś porobić z http://pl.wikibooks.org/wiki/PHP
zobacz np http://lukasz-socha.pl/php/mvc-w-praktyce-...artykulow-cz-1/
http://rynko.pl/prosta-klasa-do-zarzadzani...sion-class-php/

pełno masz tego na necie

"Programowanie obiektowe PHP kurs"

"OOP php tutorial"

Nie musisz przerabiać całego kursu. Zrób kilka tutoriali z różnymi klasami.
Np jakiś prosty system szablonów , klasa do wysyłania maila, newslettera, obsługi sesji, breadcrumbsy, paginacja, logowanie i rejestracja i poużywaj w projekcie, potestuj.

Napisz sobie później na podstawie tego własne klasy. Np do obsługi usera w bazie -> Tworzenie, edycja, pobieranie danych usera.
Tworzysz pola i metody opisujące dane jakie ma zawierać taki user i operacje jakie można na tych danych wykonywać (musisz się nad tym zastanowić, pisz to tak, żeby było jak najbardziej możliwie elastyczne i będzie można to wykorzystać w innych projektach).

Później zrób sobie następną i następną.

Tutaj masz coś bardziej skomplikowanego:
http://lukasz-socha.pl/php/routing-linkow-w-php/

Nie chodzi o to, żebyś wykorzystywał (z podanych linków) ich skrypty tylko dla tego, że są obiektowe bo często są one po prostu przykładowe, edukacyjne.
Chodzi tylko, żebyś załapał sens OOP.

Zapoznaj się z tematem automatycznego ładowania klas.

Poducz się o MVC. Zrób sobie mini prosty framework.
Wtedy Ci się nieco rozjaśni i zobaczysz, że dzięki OOP to co właśnie programujesz jest bardzo wygodne

Możesz też pozalglądać na webmastah:

http://webmastah.pl/jak-programowac-obiektowo-cz-1-wstep/

Masz tam kilka części (chyba 6) o OOP.

Programowanie obiektowe najlepiej poznaje się na językach typowo zorientowanych obiektowo jak np. JAVA, gdzie inaczej niż obiektowo nie napiszesz. Szybciej załapiesz niż w PHP

Na koniec jeszcze bym dodał, żebyś zainteresował się testami jednostkowymi i TDD. Dla php jest, na przykład, PHPUnit.
Nie jest to może związanie stricte z OOP, bo testować można i kod proceduralny, ale za to pozwala błyskawicznie wyłapać problemy i błędy w logice. Jeśli nie potrafisz czegoś przetestować, lub kombinujesz jak koń pod górkę, żeby napisać test, to jasny znak, że coś zrobiłeś źle i najlepiej będzie przemyśleć dany fragment kodu.

Test są na prawdę bardzo wartościowe. Nawet jeśli robisz to sam dla siebie.

@michaf1994 chcesz pisać strukturalnie i nie masz potrzeby pisać obiektowo to w czym problem? Pisz jak Tobie jest lepiej lub jak potrzebujesz. Nie jesteś pierwszym, który ma takie podejście i stawia takie pytanie (np. Temat: Programowanie obiektowe jak sie przekonac).


Wybacz, ale to oznacza, że nie masz pojęcia o programowaniu obiektowym. Pokaż co przeczytałeś, a może ktoś doradzi Ci co jeszcze powinieneś przeczytać. Moim zdaniem dla poczatkujacego absolutne miniumum to "PHP5 Obiekty, wzorce, narzędzia". Oczywiście jest jeszcze uznawana za najważniejsza, ksiazka Bandy czworga "Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku". Do tego podane już blogi/kursy i wiele innych materiałów w sieci.


Chciałbym dołaczyć dygresję.


Być może Tobie tak, ale innym nie.


Przecież nie ma żadnego zwiazku między systemami wbudowanymi a obiektowościa. Kod dla systemów wbudowanych bez przeszkód mógłby być obiektowy i przecież jest.


Uważasz, że wyznacznikiem sensowności jest to, że ktoś to wymyślił? Czyli, że rzeczy bezsensowne nie sa wymyślone a spadaja z nieba? Wielokrotnie można spotkać się z sytuacja w ktorej robimy coś bez sensu: "bo tak".




To już w ogóle nie wiadomo o co chodzi. Dokładnie to samo można napisać proceduralnie.


Porównywanie źle napisanego kodu strukturalnie z dobrze napisanym kodem zorientowanym obiektowo nie ma sensu, oczywiście można, tylko wnioski sa tyle samo warte co porównanie.


Naprawdę chcesz bronić tezy, że w java'ie nie da się napisać strukturalnie? Słowo kluczowe class nie czyni kodu obiektowym.

OK. Nie wyraziłem się jasno. Nie chodziło mi o to, że się nie da. Ale po prostu czasami nie ma sesnsu kombinować, bo 8/16-bitowe kontrolery mają bardzo mało pamięci, a hashowanie niestety kosztuje. C nie ma wbudowanych mechanizmów obiektowych czy enkapsulacji. Fakt, że da się je osiągnąć to jedno. Ale faktyczne zastosowanie wymaga już głębszej analizy.

Ja po prostu byłbym daleki od uogólnień typu OOP jest cacy a procedural to samo zło.

1. Oczywiście, że nie. Dałem po prostu na wstępie taki mega prozaiczny przykład, żeby zwrócić uwagę czytelnika .
Ps poza tym czytaj ze zrozumieniem: Wymyślił i używa, a nie tylko wymyślił.
Wymyślono samochód - to było sensowne. Bo ludzie tego używają
Wymyślono wielofunkcyjny scyzoryk ogrodowy - to było bez sensowne bo nikt tego nie używa (http://lista20.pl/wp-content/uploads/2013/10/wynalazki-111.png)

2. To też napisałem. Tylko, że (nie wiem czemu) wpisało mi się słowo "strukturalnie" zamiast "proceduralnie". W sumie podobnie
Chodziło o to, że robiąc to obiektowo mamy lepszą organizację kodu i jego lepsze wykorzystanie.
Chciałem to przedstawić za pomocą jakiegoś przykładu a nie teorii. Być może nie wyszło.