Конструктори плагінів WordPress не повинні визначати хуки

Здається, що конструктори плагінів WordPress все частіше стають предметом дискусій, коли справа доходить до того, що вони повинні визначати. Я вже говорив про це раніше, але це нормально час від часу повертатися до такої теми, чи не так?

Зрештою, є речі, яких ми вивчаємо, і речі, які ми змінюємо, коли отримуємо більше досвіду.

Зовсім нерідко бачити, що плагіни визначають хуки та іншу поведінку, але я не прихильник цього підходу. Замість цього я думаю, що обробка реєстрації гаків повинна виконуватися у власній функції або, що ще більш радикально, оброблятися набором класів.

Але перш ніж приступити до цього, я хочу пояснити, що має міститися в конструкторі плагінів WordPress, чому це має входити в конструктор і як це можна зробити під час роботи над плагінами.

Конструктори плагінів WordPress

З самого початку я вважаю, що конструктори слід використовувати для одного:

• Ініціалізація стану об’єкта.

Те, що визначає початковий стан об’єкта, може залежати від того, чи створено його «з нуля», чи завантажується інформація з попереднього набору (наприклад, серіалізація сеансу). Я бачу це так:

• атрибути – це іменники, які описують об’єкт,
• функції — це дієслова, які описують, що може робити об’єкт.

Функції, звичайно, виконують роботу, яку здатний виконувати цей об’єкт. Вони можуть змінювати стан об’єкта під час виклику або виконувати роботу над аргументами, переданими у функції.

Що повинно входити в конструктор?

Коли об’єкт створено, його потрібно просто налаштувати таким чином, щоб його атрибути були встановлені, а його функції готові до роботи.

Якщо в конструкторі є щось, що не впливає на початковий стан об’єкта, цього там не повинно бути.

Чому атрибути повинні бути в конструкторі?

Можливо, краще поставити це запитання:

Чому хуки не повинні бути визначені в конструкторі?

Система хуків WordPress є частиною керованого подіями шаблону проектування (якого я прихильник), але реєстрація хуків не описує стан об’єкта. Натомість на найфундаментальнішому рівні це те, що створює зв’язок із об’єктом і WordPress.

Для початкового стану об’єкта не потрібно знати про WordPress, мати будь-які його функції, налаштовані на поєднання з WordPress, або виконувати будь-яку обробку за допомогою WordPress.

Пам’ятайте, що атрибути ініціалізуються в конструкторі. WordPress не є атрибутом. Це залежність. Створити залежність означає виконати дію, яка є визначенням дієслова.

Таким чином, уся реєстрація гаків повинна виконуватися у функції.

Як ми можемо впоратися з реєстрацією гаків?

Це одна з тих тем, які можуть бути окремою публікацією або серією публікацій.

• За допомогою WordPress можна створити клас, який підтримує реєстр об’єктів і хуків.
• Також можна визначити реєстрацію гаків у функції в класі.
• Ми також можемо робити багато речей за допомогою інверсії залежностей.

Усе вищезазначене є речами, які виходять за рамки цієї публікації, але для простоти я покажу приклад того, як клас може зареєструвати свої функції у WordPress у функції 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
        );
    }
}

Таким чином ми можемо створити екземпляр об’єкта, перевірити його, використовувати тощо, але нам не потрібно мати справу з будь-чим, що стосується WordPress, без явного виклику функції init.

Як тільки це викликається, створюється залежність, потрібен WordPress, і все стає складніше.

О, і це тестування

Я хочу згадати ще один момент, який трохи виходить за межі цієї публікації, але все ще актуальний: коли справа доходить до тестування класу, ми повинні мати можливість:

1. створити екземпляр класу,
2. тестування його логіки шляхом виклику функцій,
3. передаючи йому параметри та оцінюючи його значення, що повертаються.

І ми повинні бути в змозі зробити якомога більше із цього ізольовано. Якщо в конструкторі визначено хуки, це створює негайну залежність від WordPress, яка не потрібна.

WordPress не описує стан об’єкта. Це залежність об’єкта.

У будь-якому випадку, я намагаюся підкреслити, що конструктори плагінів WordPress не повинні обробляти реєстрацію хуків, оскільки хуки не описують його стан. Вони пов’язані з тим, що робить клас, і вони не дозволяють нам тестувати об’єкт ізольовано.

Тому вони мають своє місце, але не в конструкторі.