Jeśli nie przeczytałeś pierwszego posta z tej serii, polecam, ponieważ zaczynamy pisać kod obiektowy dla WordPressa za pomocą Widgets API.
Seria ma uchwycić kilka rzeczy:
- pokazać podstawowy szkielet widżetu i dlaczego jest zorientowany obiektowo,
- przedyskutuj, jakie rzeczy powinieneś być w stanie zauważyć i dlaczego
- najpierw zaktualizuj Widget Boilerplate bezpośrednio na tej stronie, a następnie wyślij go do GitHub,
- zbuduj widget wykorzystując API z boilerplate jako fundament naszej pracy.
Ale zanim to zrobię, chcę się upewnić, że wszyscy, którzy to czytają, są zorientowani w podstawowych zasadach programowania obiektowego i mają wszystko, co jest potrzebne do zbudowania rozwiązania zorientowanego obiektowo dla WordPressa.
W tym celu polecam:
- Dwa filary programowania obiektowego: część 1 z 2
- Dwa filary programowania obiektowego: część 2 z 2
- Klasy abstrakcyjne, część 1 – zachowanie abstrakcji
- Klasy abstrakcyjne, część 2 – Klasy abstrakcyjne i interfejsy
- Niezależny programista WordPress
Jeśli przeczytałeś wszystkie te treści, świetnie. Będziesz dobrze przygotowany do tego posta i kolejnych postów. Jeśli nie, mogą być pewne dziury w reszcie tego, co zamierzasz przeczytać, ale istota postu powinna być wystarczająco jasna.
O co dokładnie chodzi?
Oto rzecz: W zeszłym tygodniu udostępniłem fragment kodu wraz z kilkoma informacjami na temat API Widgets. Zamierzam wrócić do tego nieco więcej w tym poście, zanim przejdziemy do bardziej intensywnej części kodowania z dwóch powodów:
- Chcę, aby wszyscy czytający to byli na tej samej stronie, co dotyczy pisania kodu obiektowego (przynajmniej w tym kontekście),
- Zdaję sobie sprawę, że ludzie pochodzą z różnych środowisk i chcę się upewnić, że wszyscy jesteśmy na tej samej stronie w jak największym stopniu, zanim przejdziemy dalej.
Jeśli masz doświadczenie w pisaniu kodu zorientowanego obiektowo, zwłaszcza na zaawansowanym poziomie, może ci się to wydawać prostsze; w przeciwnym razie mam nadzieję, że uzbroi cię to we wszystko, czego potrzebujesz, aby wykryć praktyki zorientowane obiektowo nie tylko dotyczące tego interfejsu API, ale także podczas czytania kodu innych osób.
Jak wykryć programowanie zorientowane obiektowo?
Być może naturalnym pierwszym pytaniem jest, dlaczego musimy być w stanie wykryć, przeczytać lub zrozumieć programowanie obiektowe przed jego napisaniem?
Słowo o złym kodzie
Krótka odpowiedź na to jest taka:
Nie musisz, ale to jest pomocne. Jeśli potrafisz czytać programowanie zorientowane obiektowo, będziesz miał przewagę w korzystaniu z tego, co oferuje jako paradygmat, ponieważ będziesz bazować na strategiach i pracy wykonanej przez innych w innych projektach.
Nie oznacza to, że nie będziemy czytać złego kodu, ale zrobimy, co w naszej mocy, aby zidentyfikować zły kod, zidentyfikować problematyczne obszary, a następnie zrobimy wszystko, co w naszej mocy, aby uniknąć włączenia go do naszej pracy.
Na razie jednak przyjrzyjmy się interfejsowi API widżetów, aby zobaczyć, co możemy zrobić, aby wykryć programowanie obiektowe.
Powrót do programowania obiektowego
W poprzednim poście nakreśliłem dwie rzeczy, które wskazują, że API jest zorientowane obiektowo (przynajmniej w pewnym stopniu):
- użycie słowa kluczowego extends ,
- funkcje, które musimy wdrożyć.
Powodem, dla którego chcę wrócić do tego tematu, jest to, że identyfikuje on dwie kluczowe rzeczy, które są częścią podstawowych zasad zorientowanych obiektowo: Dziedziczenie i implementacja funkcji (która często jest częścią klas abstrakcyjnych ).
Uwaga zanim spojrzymy na powyższe:
Kiedy spojrzysz na źródło klasy WP_Widget, zauważysz, że nie ma metod abstrakcyjnych. Ale niektóre z funkcji, które musimy zaimplementować, o których wspomnę później w tym poście, są głównymi kandydatami do metod abstrakcyjnych. I omówię też dlaczego.
Podzielmy powyższe tematy na dwie oddzielne sekcje: Dziedziczenie i Abstrakcje.
Dziedzictwo
W poprzednim poście omówiłem dziedziczenie to względna głębokość, więc nie będę tutaj omawiał tego tematu. Zaproponuję kilka słów, ale o wiele bardziej interesuje mnie omówienie abstrakcji, którą za chwilę zrobię.
Zanim jednak zagłębisz się w to zbyt daleko, zapoznaj się z następującym kodem:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Ale najpierw możemy rozpoznać, że każda klasa implementująca API Widgets musi używać dziedziczenia po prostu ze względu na słowo kluczowe extends.
Oznacza to, że istnieje poziom funkcjonalności, który zamierzamy odziedziczyć (lub otrzymać za darmo) i jest poziom funkcjonalności, który musimy wdrożyć samodzielnie.
Z podręcznika PHP :
Na przykład, gdy rozszerzasz klasę, podklasa dziedziczy wszystkie publiczne i chronione metody z klasy nadrzędnej. O ile klasa nie zastąpi tych metod, zachowają one swoją pierwotną funkcjonalność.
Kiedy jednak dziedziczysz funkcjonalność z klasy, może się okazać, że ważne jest ścisłe wywołanie konstruktora rodzica (w naszej funkcji __construct ).
Ale to rodzi to, co uważam za jeden z najważniejszych problemów z dziedziczeniem w PHP (i cały powód, dla którego chciałem zamieścić tę sekcję): Czy musimy jawnie wywoływać konstruktor rodzica?
Również zgodnie z instrukcją:
Konstruktory nadrzędne nie są wywoływane niejawnie, jeśli klasa podrzędna definiuje konstruktor. Aby uruchomić konstruktor nadrzędny, wymagane jest wywołanie metody parent::__construct() w konstruktorze potomnym. Jeśli dziecko nie definiuje konstruktora, to może być dziedziczone z klasy nadrzędnej, tak jak zwykła metoda klasy (jeśli nie została zadeklarowana jako prywatna).
Ale możemy to uprościć. Być może łatwiej to zapamiętać:
- Jeśli nasza klasa używa dziedziczenia, ale nie definiuje konstruktora, wywoływany jest konstruktor nadrzędny.
- Jeśli nasza klasa używa dziedziczenia, ale definiuje konstruktor, należy jawnie wywołać konstrukcję nadrzędną.
A może jeszcze prościej:
- Jeśli nasza klasa nie definiuje konstruktora, kod zostanie domyślnie ustawiony na konstruktor rodziców.
Ma sens? Krótko mówiąc, jeśli zdefiniujemy nasze właściwości, inicjalizację i kod w konstruktorze, pierwszy wiersz konstruktora naszej klasy powinien być wywołaniem konstruktora nadrzędnego.
Abstrakcja
Dla jasności kod źródłowy klasy WP_Widget nie zawiera metod abstrakcyjnych. Część ma to związek ze sposobem budowy klasy, część z kompatybilnością wsteczną i funkcjami PHP5.
Nie oznacza to jednak, że nie możemy określić, jakie funkcje można oznaczyć jako abstract. Właściwie myślę, że to daje argument, które klasy powinny być abstrakcyjne. Ale najpierw zdefiniujmy funkcje abstrakcyjne.
Podczas dziedziczenia z klasy abstrakcyjnej wszystkie metody oznaczone jako abstrakcyjne w deklaracji klasy rodzica muszą być zdefiniowane przez dziecko; dodatkowo metody te muszą być zdefiniowane z taką samą (lub mniej ograniczoną) widocznością.
Patrząc na źródło naszego widżetu:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Myślę, że można powiedzieć, że funkcja formularza może być oznaczona jako abstrakcyjna, ponieważ jest unikalna dla naszej implementacji. Innym sposobem myślenia o funkcjach abstrakcyjnych z punktu widzenia programowania jest zadanie sobie pytania: Które funkcje będą wymagały unikalnej funkcjonalności?
W tym przypadku funkcja formularza jest dokładnie taka, ponieważ każdy widżet będzie się różnił od tego, co renderuje. Funkcję widżetu można również oznaczyć jako abstrakcyjną, ponieważ wyświetla zawartość widżetu. Ta treść jest oczywiście oparta na funkcjonalności, którą zaimplementowaliśmy w naszej implementacji.
Co więcej, sam kod źródłowy klasy WP_Widget mówi:
funkcja WP_Widget::widget() musi być nadpisana w podklasie.’
To jest dokładnie ten typ funkcji, który powinien być oznaczony jako abstrakcyjny. Ponieważ PHP zgłosi błąd, jeśli funkcja jest oznaczona jako abstrakcyjna i nie została zaimplementowana. Nie potrzebowaliśmy żadnych wywołań funkcji umrzeć ani nic podobnego.
Jednak inne funkcje niekoniecznie będą musiały być oznaczone jako abstrakcyjne, a oto dlaczego:
- __construct wywoła konstruktor rodzica na najbardziej podstawowym poziomie i jest to konieczne do zainicjowania klasy bazowej. Nie zapomnij jednak; możemy dodać do tej metody nasze właściwości, które są unikalne dla naszej klasy.
- update używa funkcji w klasie nadrzędnej do serializacji informacji.
W ten sposób pozostały nam dwie funkcje, które można by oznaczyć jako abstrakcyjne w bardziej nowoczesnej iteracji klasy.
Dalej
W tym momencie wszyscy powinniśmy być na tej samej stronie, co dotyczy kodu obiektowego. Przynajmniej na tyle, na ile możemy przejść przez serię wpisów na blogu.
Począwszy od następnego wpisu, wrócimy do pisania kodu.
Oznacza to, że ponownie odwiedzimy WordPress Widget Boilerplate i zamierzam dokonać refaktoryzacji go w obecnym stanie, aby przyjąć bardziej nowoczesne standardy PHP.
Podzielę się zmianami, które wprowadzam, uzasadnieniami, dlaczego, a następnie opowiem o typie widżetu, który będziemy budować w oparciu o boilerplate (i możemy to zrobić).