Pierwsze dwa filary OOP
Jeśli chodzi o mówienie o programowaniu obiektowym (lub OOP), prawdopodobnie usłyszysz o Trzech Filarach Programowania Obiektowego lub Czterech Filarach Programowania Obiektowego.
W zależności od Twojego pochodzenia, być może już o nich słyszałeś, wiesz, czym one są i naprawdę nie musisz się w to zbytnio zagłębiać. Ale jeśli nie, uważam, że zrozumienie ich jest podstawą programowania obiektowego.
Omówiliśmy całą fazę analizy programowania obiektowego:
Powiedziawszy to, przejdźmy do dyskusji na temat projektowania i wdrażania. W końcu to jest to, do czego i tak wielu ludzi chce skoczyć, prawda?
Zanim napiszę jakikolwiek kod, chciałbym napisać dwa posty o czterech punktach programowania obiektowego (ponieważ jestem jednym z tych, którzy podpisują się pod ideą, że są cztery).
Dwa filary OOP
Ponownie, zrozumienie ich jest kluczem do zrozumienia podstaw programowania obiektowego. Bez nich trudno będzie poruszać się po reszcie tego, co zostanie omówione w przyszłych postach.
Porozmawiajmy więc o każdym z nich. Pierwsze dwa omówimy w tym poście, a ostatnie dwa w następnym poście.
1 Abstrakcja
Ogólnie rzecz biorąc, jest to klucz do pisania kodu obiektowego. Mam tu na myśli wszystko, co jest zawarte w klasie. Abstrahujemy ideę czegoś w klasę. W wielu książkach widzimy takie rzeczy jak Zwierzęta czy Samochody przedstawiane jako klasy.
To działa teoretycznie, ale w praktyce nie programujemy zwierząt ani samochodów (choć myślę, że w tym momencie historii można by się spierać, że tak jest, ale robię dygresję, ponieważ wiesz, co mam na myśli).
Zamiast tego będziemy abstrahować pomysły do ich klas. I tutaj jest kluczowa idea:
Klasa powinna reprezentować rzeczownik.
Oznacza to, że nie powinieneś mieć klasy, która reprezentuje coś w rodzaju „Bieganie". Zamiast tego możesz mieć coś, co działa, a zatem uruchamianie byłoby metodą. Oto ogólny podział działania abstrakcji:
- To, co ma być reprezentowane, to klasa,
- Rzeczą, którą robi, są jej metody,
- A sposób, w jaki opisujesz rzecz, zwykle można to zrobić za pomocą jej atrybutów lub właściwości.
Nie oznacza to, że nie mamy funkcji lub metod, które modyfikują jego właściwości, ale powyższe trzy punkty są dobrymi zasadami. Więc kiedy projektujesz klasę, możesz zadać takie pytania jak:
- Czy coś piszę?
- Czy piszę coś do zrobienia?
- A może piszę coś, co coś opisuje?
Ponieważ jeśli piszesz działanie, prawdopodobnie jest ono przez coś zrobione (ponieważ rzeczy podejmują działanie – robią rzeczy). A jeśli coś opisujesz, prawdopodobnie odnosi się to do czegoś (kiedy ostatnio nic nie opisałeś?)
Ma sens?
2 Hermetyzacja
Jeśli więc piszemy klasy – dobre klasy – to musimy je pisać w taki sposób, abyśmy prawidłowo hermetyzowali ich dane. A enkapsulacja to tak naprawdę tylko „duże” słowo, które odnosi się do idei zarządzania swoimi obowiązkami (lub śledzenia swoich danych).
Na przykład, gdybyśmy napisali klasę reprezentującą post WordPress, mielibyśmy klasę o nazwie Post z właściwościami takimi jak publikowanie, aktualizowanie, usuwanie, postData, publishDate, lastUpdatedData, deletedDate i tak dalej.
Wtedy mielibyśmy funkcje zaprojektowane specjalnie do podejmowania działań na instancji klasy Post .
Na przykład możemy…
- publikować,
- aktualizacja,
- lub usuń post
Te metody zostaną prawdopodobnie ujawnione w taki sposób, aby inne klasy mogły z nich skorzystać. Ponadto te metody prawdopodobnie będą również korzystać z innych właściwości, takich jak publishDate lub deleteDate.
I tu w grę wchodzi pojęcie widoczności. W programowaniu obiektowym enkapsulacja odnosi się nie tylko do idei informacji, które zawiera klasa, ale także do sposobu, w jaki ujawnia ona dane.
Odbywa się to na trzy sposoby, z których wszystkie są zdefiniowane poniżej:
- publiczne właściwości i funkcje są dostępne dla każdego, kto z nich korzysta; jednak nieruchomości publiczne zwykle nie są eksponowane. Zamiast tego upewniamy się, że można je modyfikować metodą publiczną.
- chronione właściwości i funkcje są dostępne do użycia przez klasę i każdą inną klasę, która dziedziczy z niej informacje. Zostanie to omówione bardziej szczegółowo w następnym poście.
- prywatne właściwości i funkcje to te, które mają być używane wyłącznie w kontekście danej klasy. Mogą to być właściwości używane do śledzenia wewnętrznych statusów lub metod używanych do pracy jako funkcje pomocnicze dla funkcji publicznych w celu ukończenia ich pracy.
Kontynuując tę serię, zobaczymy rolę, jaką każdy z nich odgrywa podczas pisania przejrzystych, łatwych do naśladowania, dobrze zaprojektowanych klas.
Na razie jednak ważne jest, aby zrozumieć, że te słowa, public, protected i private, są określane jako modyfikatory widoczności, ponieważ, jak możesz się upewnić, zarządzają widocznością metody lub właściwości w odniesieniu do jej klasy i klasy, które po nim dziedziczą i które z nim współdziałają.
Mówiąc o dziedziczeniu, będę o tym mówił w następnej części tej serii.
Abstrakcja, enkapsulacja i WordPress
Złe wieści: zajęcia na WordPressie
Oto rzecz: w WordPressie często widzimy bardzo, bardzo duże klasy. To nie jest dobra rzecz. W rzeczywistości są to anty-wzorce zwane boskimi klasami (pomysł polega na tym, że masz jedną klasę, która wie wszystko).
A kiedy masz boską klasę, wydaje się to wygodne, ponieważ możesz zrzucić wszystkie funkcje w jednym miejscu. Ale
- ciężko to przetestować,
- nie skaluje się,
- nie gra dobrze z inną klasą (nie mówiąc już o klasach lub bibliotekach innych firm),
- nie przystosowuje się dobrze do zmian.
Ostatecznie, kiedy to robisz, nie robisz programowania obiektowego. Bierzesz funkcje i wrzucasz je do klasy. I chcemy od tego uciec.
Dobra wiadomość: pisanie zajęć na WordPressie
Rodzi to jednak pytanie: po co uczyć się programowania obiektowego za pomocą WordPressa, jeśli nie jest to solidny przykład programowania obiektowego?
To dlatego, że nadal możesz pisać dobry kod obiektowy na WordPressie. Nadal może dobrze współpracować z WordPressem i nadal może ładnie współpracować z wieloma innymi aspektami WordPressa.
Wiem, że brzmi to sprzecznie z intuicją, ale gdy zagłębimy się w pisanie kodu obiektowego na WordPressie, powinno to stać się jasne.