Programowanie WordPress: oddzielanie obaw
Jeśli chodzi o tworzenie klas dla wtyczek do WordPressa, pytano mnie, dlaczego zawracam sobie głowę rozdzieleniem funkcjonalności na subskrybentów i na inne klasy.
Myślę, że to dobre pytanie, ponieważ pomaga zrozumieć dwie rzeczy:
- rola subskrybenta w odniesieniu do architektury WordPress,
- rola innych klas w odniesieniu do tego, co tworzysz (i jak to może pomóc w innych rzeczach, takich jak testowanie jednostkowe i tak dalej).
Pomyślałem więc, dlaczego nie odpowiedzieć w formie krótkiego posta? Będzie dokumentować, dlaczego stoi za czym [i da mi miejsce do aktualizacji, jeśli coś zmieni się w przyszłości].
Programowanie WordPress: subskrybenci i obiekty domeny
Rozważam klasy, które nie są obiektami domeny subskrybenta, które pochodzą z podejścia programistycznego do projektowania opartego na domenie.
To wykracza poza zakres tego postu, ale warto wspomnieć, jeśli nie z innego powodu, ponieważ nadaje to kontekst temu, co w przeciwnym razie byłoby uznane za żargon.
1 Subskrybenci
Ale najpierw subskrybenci.
Ponieważ WordPress opiera się na systemie przechwytującym — systemie opartym na wzorcu projektowym opartym na zdarzeniach — warto mieć klasę, która reaguje na każde zdarzenie.
Może to dotyczyć dowolnego wstępnie zdefiniowanego haka WordPress lub dowolnych haków niestandardowych. Nie ważne.
I nie chcę, aby klasa była bardziej skomplikowana niż to konieczne, więc myślę o nich w ten sposób:
Abonent odpowiada za każdym razem, gdy wydarzy się określone zdarzenie.
I to wszystko. To zdarzenie może być czymś w rodzaju after_theme_setup lub the_content, a nawet init. To nie ma znaczenia.
Czeka na zdarzenie, a następnie odpowiada w tym, co zdecydujemy, za pomocą innego kodu (w którym w grę wchodzą obiekty domeny).
2 obiekty domeny
Mogą być również nazywane obiektami biznesowymi lub podobnie. Ich idea jest następująca:
Wszystko, co robimy w programowaniu obiektowym, ma na celu rozwiązanie konkretnego problemu i ma to na celu zrobienie tego poprzez jakiś rodzaj obiektu, który reprezentuje obiekt ze świata rzeczywistego lub przynajmniej konkretną ideę.
Tak więc za każdym razem, gdy pracujesz nad zapewnieniem komuś rozwiązania, pisane przez Ciebie klasy — obiekty, którymi staną się po utworzeniu instancji — są obiektami domeny.
Są to również klasy, które wykonują rzeczywistą pracę. Możesz więc myśleć o tym w trzech elementach:
- WordPress. Podstawowa aplikacja, oczywiście, która podnosi zdarzenie, na które reagują subskrybenci.
- Abonenci. Zbiór klas odpowiedzialnych za nasłuchiwanie określonego zdarzenia, a następnie tworzenie instancji odpowiedniego obiektu do obsługi kodu.
- Obiekty domeny. Kod, który faktycznie wykonuje pracę polegającą na pobieraniu zestawu danych, operowaniu na nim, a następnie potencjalnie zwracaniu wartości.
Obiekty domeny są miejscem, w którym żyje kod faktycznie robienia czegoś. Subskrybenci są jak połączenie między WordPressem a wspomnianą funkcjonalnością.
Subskrybenci mówią: „To wydarzenie się wydarzyło i ta klasa jest zdolna i odpowiedzialna za obsługę jego wyników".
A co z testowaniem i tak dalej?
Wcześniej w poście mówiłem o tym, jak obiekty domeny są powiązane z testowaniem jednostkowym i innymi technikami programowania związanymi z kontrolą jakości.
Chociaż nie jest to post zawierający szczegóły, warto wspomnieć, że utrzymywanie obiektów domeny i subskrybentów oddzielonych od siebie (i z kolei od WordPressa) pozwala nam tworzyć wystąpienia, testować i pracować z obiektami, które są wywoływane przez subskrybentów bez konieczności włączania WordPressa do naszej pracy.
A to może być niezwykle pomocne przy budowaniu większych rozwiązań. Ale sednem tego, jak to zrobić, jest treść innego posta.