Temat: [PHP/JS/Teoria] Programowanie obiektowe

Też się podbiję pod kolegę i proponuje założenie odrębnego tematu z PHP wyłącznie. Jakby ktoś ogarniał i mógł zrobić lekcje programowania w php to już w ogóle było by super. Jakby @Killavus ; chciał albo mógł znowu zrobić coś na podobiznę wcześniejszego tematu z programowania.

Po pierwsze - musisz znać podstawowe pojęcia jak funkcje , zmienne, instrukcje warunkowe i tak dalej. Bez tego nie masz po co patrzeć na programowanie obiektowe.

W skrócie - programowanie obiektowe wprowadza pojęcie ,,obiektu" jako logicznej jednostki wykonującej zadanie. Obiekt jest definiowany przez tzw klasę, która definiuje jego pola ( właściwości ) i metody ( sposoby oddziaływania na obiekt ).

Aby prościej to zobrazować, pokażę Ci przykład z życia wzięty:

Odpowiednio wykorzystywane pozwala na znaczne zwiększenie czytelności kodu i zależności miedzy logicznymi jednostkami a także ułatwia ponowne wykorzystanie kodu.

To może je spróbuję tak zdeczka wprowadzić. Nie będzie to może szczyt wiedzy programistycznej ale dla laika najlepiej tlumaczyć na chłopski rozum. Nie znam PHP jeżeli chodzi o programowanie obiektowe, dlatego moje nauczanie będę prowadził w C#, jednak uważam że będzie to na tyle proste że zrozumiesz a w formie ćwiczenia stworzysz podobny kod w PHP.

Programowanie obiektowe jest to sposób programowania, gdzie używasz obiektów. Czym są obiekty? No tak naprawdę obiektem może być wszystko: przedmioty, figury, ludzie, samochody. Te ostatnie są bardzo prostym przykładem więc na ich podstawie omówię najważniejsze kwestie. Samochodów może być dużo, każdy z nich posiada wspólne cechy, czyli każdy z nich jest jakiejś marki, ma jakiś kolor, jakiś silnik i jakiś przebieg. Znamy wszystkie parametry (marka, kolor, silnik, przebieg), ale nie znamy ich wartości - to jest własnie KLASA. Teraz spośród wszystkich samochodów możemy stworzyć jeden, taki który posiada kolor, silnik i markę - jest to OBIEKT. Obiekty tak jak już mówiłem, tworzymy używając klasy. Zatem od czego zaczynamy naszą zabawę z programowaniem obiektowym? Od napisania naszej klasy!
Oto jak wygląda klasa o jakiej pisaliśmy: nazwa Samochód, parametry: marka, kolor, silnik, przebieg.

Wszystko co dotyczy tej klasy, musi zawierać się w klamerkach { }.
Jak widzimy, tworzenie klasy rozpoczynamy od wyrazu class, następnie nazwa. Logiczne, nie ma co tłumaczyć.
W klamrach już jest ciekawiej, widzimy
Po kolei: public - o tym później - przy hermetyzacji :) string - typ naszego pola (parametru) kolor -nazwa naszego pola.

Mamy już klasę, teraz aby zrobić nasz obiekt potrzebny nam będzie KONSTRUKTOR. Czym jest konstruktor? jest to metoda, która wywołuje się przy tworzeniu obiektu. Może brzmieć strasznie, ale to nic trudnego. Metoda to funkcja w klasie. Metoda to tak łopatologicznie: zadanie jakie może realizować klasa np. jedź(), albo zapal_swiatla().
Jak stworzyć konstruktor, stworzyć metodę o takiej samej nazwie co klasa! czyli dopisać pod polami:
Kiedy mamy już klasę z konstruktorem, możemy stworzyć obiekt! Jak go stworzyć? W kodzie programu (nie w klasie!) napisać instrukcję:
To jest nasz pierwszy obiekt! Ale zaraz, nasz samochód jeszcze nie ma ani koloru, ani marki, nic nie ma. Co robimy? Można by po kolei odwoływać się do pól i je ustawiać np:
Można ale to jest brzydkie. Możemy to wszystko zrobić w konstruktorze!
Tworzymy więc kolejny KONSTRUKTOR Z ARGUMENTAMI Czym są argumenty? są to już konkretne wartości naszego samochodu. Konstruktor ten robimy np. tak:
A jak stworzyć dzięki niemu obiekt?
Dokładnie tak jak poprzednio, ale w nawiasach wpisujemy cechy naszego samochodu, w takiej samej kolejnosci.
Teraz temu naszemu samochodowi, możemy powierzyć jakieś zadania, prawda? Jednak te zadania trzeba mu najpierw zapisać w klasie tworząc metody. Zróbmy prostą metodę jedz(), która wypisze nam na ekran jakiś tekst. Pod konstruktorami dopiszmy:
Jak rozkazać samochodowi żeby jechał? Bardzo podobnie jak "brzydko" przypisywalismy wartości do pól, mianowicie piszemy nazwę naszego obiektu, a potem po kropce nazwę metody z nawiasami:
Co się pojawi na ekranie? To Twoja praca domowa, koniec lekcji, odrób pracę domową i stwórz podobny kod w PHP. Jak będziesz chciał dalej się pouczyć to mogę Ci wytłumaczyć na czym polegają rzeczy ściśle związane z programowaniem obiektowym, mianowicie: dzidziczenie, hermetyzacja, polimorfizm.

Pozdrawiam! :)

Dobra napisałeś co to jest, ale nie wiadomo czym to się różni od zwykłego programowania. (Wiem, że teraz ci co ogarniają temat pocisną mnie że obiektowe to też zwykłe programowanie).

Napiszę w sumie to co wyczytałem w kursie C++. Czyli, dlaczego powstało programowanie obiektowe:

Kiedyś, nie było czegoś takiego jak klasa. Były tylko zmienne i funkcje. I tak np. Jak chciało się posortować tablicę liczb. Tworzyło się funkcję sortuj która jako argument pobierała tablicę do posortowania, oraz opcjonalnie sposób - malejąco/rosnąco.

Funkcje taką wykonywało się:
Było to nie przyjazne człowiekowi, gdyż patrząc w naszym świecie np. na naszą drukarkę - jak ona drukuje, to mówi się, że: Drukarka wydrukowała dokument. A w programowaniu mówiło się wtedy: Drukowanie następuje na drukarce, i drukuje dokument. Czyli, najpierw jest czynność a później coś co tą czynność wykonuje.

Programowanie obiektowe odwraca ten proces na bliższy naszemu rozumowaniu.

Dziś tworzy się klasę drukarka, która ma funkcję drukuj, której przekazuje się tylko 1 argument - sposób sortowania.

I tak np. teraz: Zamiast wykonywać $tablica = sortuj($tablica,'malejaco');, wykonuje się:
Ten pierwszy parametr funkcji który tym razem zniknął jest z góry przypisany do tego co znajduje się przed strzałką - czyli naszego obiektu (zmiennej $tablica), który tworzy się tak jak wcześniej napisał @Havaran .

W takim sposobie programowania lepiej widać co na czym jest wykonywane. Po pierwsze - bierzesz zmienną tablica, po drugie, wykonujesz na niej akcję sortuj.



Druga zaleta programowania obiektowego to możliwość łatwiejszej rozbudowy.

Jeśli masz już duży projekt i zaawansowany - np baze danych wszystkich modeli samochodow swojej marki.
Wszystkie te modele to nic innego jak nowa zmienna typu klasowego (nazwa utworzonej klasy), posiadaja takie same parametry jak klasa. I jeśli już stworzyłeś 140 modeli, jak chciałbyś dodać im dodatkowy parametr, np. pomysłodawca wyglądu - imie osoby ktora wymyslila ten wyglad. Musiałbyś normalnie wyedytować okolo 140 linijek i dopisac im nowego wlasciciela. Tworzac zmienna typu klasowego, wystarczy ze w klasie dopiszesz dodatkowe pole (zmienna). I wszystkie obiekty tego typu beda mogly miec przypisanego autora.



Do tego dochodzą takie pojecia jak:
Hermetyzacja danych, dziedziczenie, interfejsy, polimorfizm. To juz grubsze zagadnienia do znalezienia opisu w necie.

Hermetyzacja to gówno. O ile rozumiem, że w konkretnych przypadkach pojedyncze pole lepiej zabezpieczyć, to w ogólności to jest bez sensu. Jeśli ktoś inny zajrzy do mojego kodu i go nie rozumie i coś zepsuje to jego problem... Z reszta wspólna praca nad kodem to trochę podchodzi pod poligamię...

Nie masz racji. Hermetyzacja jest jedną z najważniejszych rzeczy w OOP, dostęp do pól jest nawiązaniem statycznym = niepodatnym na modyfikację oraz rozwiązaniem dość ciężkim do testowania, toteż złą praktyką jest tworzenie pól publicznych. ZAWSZE z zewnątrz tworzymy settery i gettery aby dać możliwość nadpisania funkcjonalności.

Tja, ale jak potrzebuję tylko dostępu bezpośredniego to jest to nieźle irytujące. Rozumiem jak setter musi dbać o poprawność danych to zakładam private żeby nie zapomnieć, ale no bez przesady żeby wszystko i zawsze było prywatne lub chronione...

Dzisiaj tworzenie aplikacji to tylko praca grupowa. Dziś już nie ma jednoosobowych twórców aplikacji komercyjnych. Czasy uber geeków siedzących 24h mineły. Potwierdzone info, od specjalisty ds. jakości kodu, i zarządzania zespołami programistów w grupie Allegro.

Chcesz coś zawojować i pracować jako programista? - Jesteś zmuszony pracować wspólnie nad kodem.

Dodatkowy pierdyliard linii kodu i mess. Jeśli jakieś IDE mi to samo dorobi no to już trudno, ale jak mam klepać to ręcznie to tylko gdzie jest mi niezbędne.
A praca w kilka osób nad jednym kodem to tylko gdy ja jestem szefem i mogę tyrać ludzi, że coś źle robią

Okej kolego, wobec tego masz klase z polami publicznymi. jak chcesz:
a) stworzyć mock do takiej klasy
b) mieć możliwość zmiany zachowania przy accessowaniu pola

Chętnie posłucham ;]

Jak jest potrzebne to robię, ale to raczej i tak settery. Podaj mi konkretny przykład, gdzie bez zamknięcia całej klasy wszystko wybuchnie.
setValue(type v)
{
value=v;
}
type getValue()
{
return value;
}
są kompletnie bezużyteczne, setter z zablokowanym publicznym dostępem ma sens jeśli się do niego wlepi sprawdzenie poprawności, co z drugiej strony trochę narusza teoretyczną funkcję settera, który ma być bezużyteczny...
Sensownego zastosowania gettera nie widzę (oh well, jak zapomnę drugiej równości w ifie to może trochę pomóc...)

stworzyć syntetyczny obiekt? np, zamiast wołać o.setShit(z) robię o.shit = z; where's the problem

robienie na siłę niektórych rzeczy "bo konwencja" nie ma sensu, język jest naszym narzędziem, a nie panem

A sytuacja taka:

Zrobiłem sobie publiczne pole. Odwołałem się do o.shit w 50 miejscach, w 4 plikach, i gdzieś jeszcze gdzie już nawet nie pamiętam.

Nagle po kilku dniach pracy widzę, że o.shit nie powinno mieć nigdy wartości 3.14.

Teraz muszę dodać getter i setter i ustawić mu odpowiedniego ifa czy coś co obsłuży tą liczbę. I znaleźć wszystkie wystąpienia o.shit i zamienić na o.getShit();

Podczas gdy gdybym od początku zrobił setter i getter. Wystarczu dopisać jednego ifa.

Teraz jak masz po 10 takich pól w 3 klasach, robota się kumuluje.

A wystarczyło zrobić to na początku. Lenistwo początkowe później się odbija.