Роз’єднання логіки домену в WordPress
Пам’ятайте, що WordPress використовує шаблон проектування, керований подіями, і хоча ми часто посилаємося на дії та фільтри, концепція зводиться до хуків. Потік керування через програму виглядає приблизно так:
- Виконати програму,
- Щоразу, коли програма натрапляє на хук (у WordPress ми побачимо
do_actionабоapply_filters), повторюйте всі зареєстровані хуки, - Повернути управління програмі,
- Виконати до кінця.
Це не зовсім відрізняється від шаблону «Видавець/Підписник» (або PubSub, скорочено), але є ключова відмінність: шаблон, керований подіями, просто сигналізує про те, що щось сталося, і якщо є гачки, вони спрацюють. Патерн PubSub скаже зареєстрованому підписнику щось зробити.
У будь-якому випадку, повернемося до хуків у WordPress. Зберегти дві концепції хуків, які ми маємо, можна найпростіше зробити, подумавши про них так:
- Дії для того, щоб щось робити,
- Фільтри призначені для обробки даних.
Якщо ви хочете підійти до розробки WordPress в об’єктно-орієнтований спосіб, тісно пов’язувати свій код із ядром WordPress, реєструючи свої класи через підключення до основної програми, не є гарною ідеєю.
Іншими словами, не реєструйте свою бізнес-логіку в WordPress. Тримайте їх окремо. Ось лакмусовий папірець для того, щоб перевірити, чи ваша робота тісно пов’язана з WordPress: якщо ви не можете запустити модульний тест свого класу, не завантажуючи WordPress, це тісно пов’язано.
Так яке рішення? Делегування.
На мій погляд, логіка домену та бізнес-логіка взаємозамінні, тож якщо ви читали про це попередні публікації, і я говорив про них різними способами, ви знаєте чому.
Далі, ідея делегування логіки від WordPress до класу для доменної логіки в WordPress виконується класом-посередником, який відповідає за наступне:
- Підписавшись на хук,
- Передача роботи класу.
Я знаю, що класи повинні робити «одну справу добре», але що, якщо це одне — делегування?
передавати (повноваження, функції тощо) іншому як агенту
І щоб належним чином передати функції іншому агенту або, у нашому випадку, класу, ви повинні мати можливість знати, що ви делегуєте. Іноді, щоб зробити одну справу, потрібно знати кілька частин інформації.
Отже, як це виглядає на практиці? Уявіть, що у вас є функція [AbstractSubscriber](https://github.com/tommcfarlin/remove-empty-shortcodes/blob/master/src/Subscriber/AbstractSubscriber.php)to, яка візьме назву хука в свій конструктор:
А потім, як тільки це буде зроблено, loadфункція надішле роботу до класу, відповідального за фактичну обробку.
Візьмемо, наприклад, цей код із Remove Empty Shortcodes :
Клас підписується на певну подію, наприклад [the_content](https://developer.wordpress.org/reference/functions/the_content/), а потім делегує роботу класу постобробки вмісту.
Це буквально дозволяє файлу завантаження плагіна створювати екземпляр делегату. Потім делегат підключається до WordPress, і коли WordPress переходить до належної точки виконання, делегат передає відповідальність класу, відповідальному за його обробку.
Вся ця архітектура не тільки повністю придатна для повторного використання (див. використання абстрактного класу вище), але й дозволяє нам відокремити логіку домену від WordPress і протестувати її окремо.
Більше про розділення інтересів
Я написав кілька інших дописів про розділення проблем:
- Розділення інтересів за допомогою шаблонів WordPress
- Розділення запитів і допоміжних функцій
- Програмування WordPress: розділення проблем