Konstruktory wtyczek WordPress wydają się być coraz bardziej przedmiotem dyskusji, jeśli chodzi o to, co należy zdefiniować. Mówiłem o tym wcześniej, ale można od czasu do czasu wracać do takiego tematu, prawda?
W końcu są rzeczy, których się uczymy i które zmieniamy w miarę zdobywania doświadczenia.
Nie jest niczym niezwykłym, że wtyczki definiują hooki i inne zachowania, ale nie jestem fanem tego podejścia. Zamiast tego myślę, że obsługa rejestracji haków powinna być wykonywana w jej własnej funkcji lub, jeszcze bardziej drastycznie, obsługiwana przez zestaw klas.
Ale zanim zajmę się tym, chcę wyjaśnić, co powinno znaleźć się w konstruktorze wtyczek WordPress, dlaczego powinno się znaleźć w konstruktorze i jak można to obsłużyć podczas pracy nad wtyczkami.
Konstruktorzy wtyczek WordPress
Od początku uważam, że konstruktorów należy używać do jednego:
- Inicjowanie stanu obiektu.
To, co definiuje stan początkowy obiektu, może zależeć od tego, czy został on utworzony „od zera", czy też jest ładowany informacjami z poprzedniego zestawu (np. serializowana sesja). Sposób, w jaki to widzę:
- atrybuty to rzeczowniki opisujące obiekt,
- funkcje to czasowniki opisujące, co obiekt może zrobić.
Funkcje oczywiście wykonują pracę, którą obiekt jest w stanie wykonać. Mogą modyfikować stan obiektu po wywołaniu lub mogą pracować na argumentach przekazanych do funkcji.
Co powinno znaleźć się w konstruktorze?
Kiedy obiekt jest konstruowany, należy go po prostu ustawić w taki sposób, aby jego atrybuty były ustawione, a jego funkcje były gotowe do pracy.
Jeśli w konstruktorze jest coś, co nie wpływa na stan początkowy obiektu, nie powinno tego tam być.
Dlaczego atrybuty powinny znajdować się w konstruktorze?
Być może lepszym sposobem na zadanie tego pytania jest:
Dlaczego hooki nie powinny być definiowane w konstruktorze?
System hooków WordPressa jest częścią wzorca projektowania sterowanego zdarzeniami (którego jestem fanem), ale rejestracja hooków nie opisuje stanu obiektu. Zamiast tego, na najbardziej podstawowym poziomie, jest to coś, co tworzy relację z obiektem i WordPressem.
Początkowy stan obiektu nie musi wiedzieć o WordPressie, nie musi mieć żadnej z jego funkcji połączonych z WordPress ani nie musi wykonywać żadnych operacji za pomocą WordPress.
Pamiętaj, atrybuty są inicjowane w konstruktorze. WordPress nie jest atrybutem. To zależność. Stworzenie zależności to podjęcie działania, które jest definicją czasownika.
Dlatego wszystkie rejestracje podpięć powinny być wykonywane w funkcji.
Jak możemy obsłużyć rejestrację haka?
To jeden z tych tematów, które mogą być samodzielnym postem lub serią postów.
- Za pomocą WordPressa można stworzyć klasę, która prowadzi rejestr obiektów i hooków.
- Możliwe jest również zdefiniowanie rejestracji podpięcia w funkcji w klasie.
- Możemy również zrobić wiele rzeczy z odwróceniem zależności.
Wszystkie powyższe są rzeczami, które wykraczają poza zakres tego postu, ale dla uproszczenia pokażę przykład, jak klasa może zarejestrować swoje funkcje w WordPressie w funkcji init :
<?php
namespace AcmeAdmin;
use AcmeAdminInterfaces;
class JavaScript_Assets implements InterfacesAsset {
private $assets_dir;
private $js_dir;
public function __construct() {
$this->assets_dir = trailingslashit(
plugin_dir_url( __FILE__ ). 'assets'
);
$this->js_dir = trailingslashit( $this->assets_dir. 'js' );
}
public function init() {
add_action(
'admin_enqueue_scripts',
array( $this, 'enqueue') );
}
public function enqueue() {
wp_enqueue_script(
'toggle-admin-notices',
$this->js_dir. 'admin.js',
array( 'jquery' ),
false
);
}
}
W ten sposób jesteśmy w stanie utworzyć instancję obiektu, przetestować go, użyć itd., ale nie musimy zajmować się niczym związanym z WordPressem bez jawnego wywołania funkcji init.
Po wywołaniu tworzona jest zależność, potrzebny jest WordPress i sprawy stają się bardziej skomplikowane.
Och, i ta rzecz testująca
Chcę wspomnieć o jeszcze jednym punkcie, który jest nieco poza zakresem i punktem tego postu, ale nadal jest istotny: jeśli chodzi o testowanie klasy, powinniśmy być w stanie:
- utworzyć instancję klasy,
- testowanie jego logiki przez wywoływanie funkcji,
- przekazywanie jej parametrów i ocenianie jego zwracanych wartości.
I powinniśmy być w stanie zrobić jak najwięcej w odosobnieniu. Jeśli hooki są zdefiniowane w konstruktorze, tworzy to natychmiastową zależność od WordPressa, która nie powinna być potrzebna.
WordPress nie opisuje stanu obiektu. To zależność obiektu.
W każdym razie chodzi mi o to, że konstruktory wtyczek do WordPressa nie powinny zajmować się rejestracją hooków, ponieważ hooki nie opisują ich stanu. Są one powiązane z czymś, co robi klasa i uniemożliwiają nam testowanie obiektu w izolacji.
Mają więc swoje miejsce, ale nie w konstruktorze.