TL;DR: я считаю, что использование реестра, подписчиков и сервисов очень полезно при создании ориентированных на серверную часть плагинов и утилит для WordPress. В этом посте рассказывается, как это сделать.
После многих лет работы с шаблонами проектирования, объектно-ориентированным программированием и WordPress неизбежно возникнут общие способы решения проблем.
Так мы получили объектно-ориентированные шаблоны проектирования, так что, возможно, это их вариант, ориентированный на WordPress.
Хотя я писал о таких вещах, как реестры, в предыдущих статьях (и даже не таких уж старых ), никогда не будет лишним вернуться к той же теме, особенно когда есть что добавить к предыдущему варианту.
Реестр, подписчики и службы
Все, что описано ниже, следует понимать в контексте плагина WordPress. То есть это не должно восприниматься как способ работы с любыми другими фреймворками, языками, приложениями или при использовании его с любыми другими шаблонами.
Помните об этом, читая это.
В любом случае, общая идея комбинации этих типов объектов следующая:
- Реестр обрабатывает всех подписчиков,
- Подписчики прослушивают хуки в WordPress (те, которые существуют, или даже пользовательские хуки),
- Службы выполняют фактическую работу всякий раз, когда подписка отправляет их.
Цель состоит в том, чтобы зарегистрировать классы, ответственные за диспетчеризацию работы, в одном месте. Вот и все.
Кроме того, это также упрощает разделение вещей, поэтому, если вы хотите протестировать свои службы изолированно, это намного проще, потому что они не обязательно тесно связаны с WordPress. А если они есть, то можно имитировать данные, которые нужно передать в заданную функцию, а затем оценить результат.
Это не статья о тестировании, так что вернемся к реальным классам.
Реестр
По определению, целью реестра является отслеживание вещей. Когда дело доходит до реализации этого шаблона в WordPress, идея заключается в том, что реестр может отслеживать подписчиков (о чем я расскажу позже в этой статье).
Фото Денни Мюллера на Unsplash
Кроме того, идея состоит в том, что когда придет время, которое, скорее всего, будет другим, независимо от структуры вашего плагина, все подписчики будут экземплярами. Однако к этому моменту вы, вероятно, захотите сделать это в начале жизненного цикла WordPress.
Тем не менее, вот пример кода для регистрации подписчиков:
private $subscribers = [
AssetSubscriber::class,
// ...
DeletedUserSubscriber::class,
];Далее, вот функция для создания экземпляров подписчиков.
Эти блоки могут быть частью одной и той же функции или могут быть отдельными в зависимости от ваших потребностей.
Подписчики
Как уже упоминалось, подписчики — это способ:
- Слушайте определенный хук в WordPress
- Отправьте сервис для выполнения любой работы, предназначенной для данного хука.
Итак, предположим на мгновение, что вы хотите что-то делать всякий раз, когда пользователь удаляется. Вы хотите создавать экземпляр службы через подписчика всякий раз, когда происходит этот хук.
Фото Ли Кэмпбелл на Unsplash
В качестве примера:
Обратите внимание, что подписчик знает о сервисе (хотя он не поддерживает от него зависимости, поскольку является просто посредником между WordPress и сервисом) и указывает хук на сервисе, который его создает.
Услуги
Наконец, сервисы — это объекты, которые выполняют всю тяжелую работу в плагине. Это означает, что если им нужно прочитать или записать в базу данных, файловую систему, сеть, обработать данные и т. д., все это происходит в их контексте.
Фото Эрика Маклина на Unsplash
Они могут знать о других классах, а могут и не знать. Они могут реализовывать интерфейс или абстрактный класс или нет. Это действительно выходит за рамки этого поста. Но дело в том, что на примере хука выше, если вы хотите что-то сделать при удалении пользователя, вы делаете это внутри сервиса.
Например:
class DeletedUserService
{
public function add(string $hook)
{
add_action($hook, [$this, 'deletedUser'], 99, 1);
}
public function deletedUser(int $userId)
{
$user = get_userdata($userId);
if (false === $user) {
return;
}
// Do work with the user that's being deleted.
}
}И это конец. После запуска службы управление будет возвращено WordPress, и приложение продолжит работу в обычном режиме.
Все вместе сейчас
Предполагая, что у вас есть загрузочный файл для вашего плагина, что в большинстве случаев так и происходит, поскольку именно здесь определяется требуемый плагин, требуется автозагрузчик и происходит создание экземпляра самого плагина.
Если вам интересно увидеть более полное решение, демонстрирующее, как использовать приведенный выше код на практике, сообщите мне об этом в Твиттере. Таким образом, я буду знать, чтобы продолжить и подготовить еще одну статью. 🙂