Конструкторы плагинов WordPress становятся все более и более предметом споров, когда речь заходит о том, что они должны определять. Я уже говорил об этом раньше, но можно время от времени возвращаться к такой теме, верно?
В конце концов, есть вещи, которым мы учимся, и вещи, которые мы меняем по мере накопления опыта.
Нередко можно увидеть плагины, определяющие хуки и другое поведение, но я не сторонник такого подхода. Вместо этого я считаю, что обработка регистрации хука должна выполняться в отдельной функции или, что еще более радикально, обрабатываться набором классов.
Но прежде чем углубиться в это, я хочу объяснить, что должно быть в конструкторе плагинов WordPress, почему это должно быть в конструкторе и как это можно обрабатывать при работе с вашими плагинами.
Конструкторы плагинов WordPress
С самого начала я думаю, что конструкторы должны использоваться для одной цели:
- Инициализация состояния объекта.
То, что определяет начальное состояние объекта, может зависеть от того, создан ли он «с нуля» или загружается ли он информацией из предыдущего набора (например, сеанс сериализуется). Как я это вижу:
- атрибуты — это существительные, которые описывают объект,
- функции — это глаголы, описывающие, что может делать объект.
Функции, конечно же, выполняют ту работу, на которую способен объект. Они могут изменять состояние объекта при вызове или работать с аргументами, переданными в функции.
Что должно быть в конструкторе?
Когда объект построен, его нужно просто установить таким образом, чтобы его атрибуты были установлены, а его функции были готовы к работе.
Если в конструкторе есть что-то, что не влияет на начальное состояние объекта, его там быть не должно.
Почему атрибуты должны быть в конструкторе?
Возможно, лучше задать этот вопрос так:
Почему хуки не должны быть определены в конструкторе?
Система хуков WordPress является частью шаблона проектирования, управляемого событиями (я фанат этого), но регистрация хуков не описывает состояние объекта. Вместо этого, на самом фундаментальном уровне, это то, что создает отношения с объектом и WordPress.
Исходному состоянию объекта не нужно знать о WordPress, устанавливать какие-либо из его функций для связи с WordPress или выполнять какую-либо обработку с помощью WordPress.
Помните, атрибуты инициализируются в конструкторе. WordPress не является атрибутом. Это зависимость. Создать зависимость означает совершить действие, которое является определением глагола.
Таким образом, вся регистрация ловушек должна выполняться в функции.
Как мы можем справиться с регистрацией хуков?
Это одна из тех тем, которая может быть отдельным постом или серией постов.
- В WordPress можно создать класс, который поддерживает реестр объектов и хуков.
- Также возможно определить регистрацию хука внутри функции в классе.
- Мы также можем сделать ряд вещей с инверсией зависимостей.
Все вышеперечисленное выходит за рамки этого поста, но для простоты я покажу пример того, как класс может зарегистрировать свои функции в WordPress в функции инициализации :
<?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
);
}
}
Таким образом, мы можем создать экземпляр объекта, протестировать его, использовать и т. д., но нам не нужно иметь дело ни с чем, связанным с WordPress, без явного вызова функции инициализации.
Как только это вызывается, создается зависимость, требуется WordPress, и все становится сложнее.
О, и эта штука для тестирования
Я хочу упомянуть еще об одном моменте, который немного выходит за рамки этого поста, но все еще актуален: когда дело доходит до тестирования класса, мы должны иметь возможность:
- создать экземпляр класса,
- тестирование его логики путем вызова функций,
- передавая ему параметры и оценивая возвращаемые значения.
И мы должны быть в состоянии сделать как можно больше в изоляции. Если хуки определены в конструкторе, он создает немедленную зависимость от WordPress, которая не нужна.
WordPress не описывает состояние объекта. Это зависимость объекта.
В любом случае, я пытаюсь подчеркнуть, что конструкторы плагинов WordPress не должны обрабатывать регистрацию хуков, потому что хуки не описывают его состояние. Они связаны с чем-то, что делает класс, и не позволяют нам тестировать объект изолированно.
Так что место у них есть, но не в конструкторе.