Коли використовувати субакції WordPress (і що це таке?)
Нещодавно я ознайомився з процесом використання конструктора класу, щоб запобігти роботі плагіна, якщо його очікувана залежність не завантажується.
Хоча я не вважаю цю конкретну стратегію проблемою для одноразової залежності або в певних ситуаціях, є способи, якими це може призвести до запаху коду.
Це також заважає нам використовувати нативну функцію Core під назвою WordPress subactions:
https://twitter.com/JJJ/status/822265137935646720
Але перед тим, як дивитися на субакції, я хочу переконатися, що я чітко розумію проблеми використання умовного підходу (на відміну від субакцій), які можуть породжуватися запахами коду.
Підрозділи WordPress
Є багато способів пояснити запахи коду, але мій улюблений спосіб походить від Мартіна Фаулера :
…запахи — це певні структури в коді, які вказують на порушення фундаментальних принципів дизайну та негативно впливають на якість дизайну.
Є ще одна чудова сторінка про запахи коду на Source Making, яку я рекомендую прочитати, якщо у вас є можливість.
І те, як умовні оператори можуть призвести до запаху коду, дуже просте: вони можуть засмічувати ваш код величезним набором операторів, які містять багато перевірок class_exists.
І це проблема.
Кожного разу, коли ви вводите іншу залежність у свій код, ви в кінцевому підсумку додаєте ще одну умовну перевірку, щоб побачити, чи присутній клас у програмі WordPress.
Я вважаю, що можна робити це за допомогою однієї залежності – можливо, навіть двох залежностей – і якщо ви працюєте на «достатньо високому» рівні у своїй архітектурі, але це не те, як належним чином впоратися з багатьма залежностями чи на нижчому рівні в ваш плагін.
Ось тут і з’являються субакції WordPress. Ви можете побачити список субакцій у твіті від Джона вище.
У Кодексі bbPress також є офіційне визначення субдій :
Ці внутрішні дії можна розглядати як «суб-дії», і вони дозволяють вам додавати або змінювати порядок дій WordPress за потреби для плагінів, які залежать від bbPress.
І ви можете побачити приклад цього в цьому файлі.
Звичайно, це визначення стосується bbPress, але це не означає, що воно не застосовується до того, що ми робимо в WordPress.
Приклад: якщо ви коли-небудь використовували do_action для визначення користувацьких дій або скористалися перевагами хука, наданого кимось іншим за межами ядра WordPress, тоді ви знайомі зі стратегією реалізації додаткової дії.
Іншими словами, субакції WordPress — це просто дії, за допомогою яких ми можемо змінити порядок, у якому наш плагін залежить від іншого плагіна.
Те, як це реалізовано, може відрізнятися залежно від контексту вашої роботи, але найпопулярнішим і найбільш «правильним» способом у WordPress є, мабуть, використання аргументу пріоритету, коли ваш плагін завантажується.
Тобто встановіть пріоритет залежності та переконайтеся, що це відбувається раніше, ніж активується ваш плагін.
Існують альтернативні методи, які можна використовувати, як-от зміна поведінки плагінів щоразу, коли вони активовані чи ні, але це виходить за межі цієї конкретної публікації, і це може негативно змінити взаємодію з користувачем (не менше WordPress загалом).
Незважаючи на це, справа в тому, що коли справа доходить до використання субакцій WordPress, об’єктно-орієнтованого програмування та керування залежностями третіх сторін, переконайтеся, що рішення, які ви приймаєте, не пошкодять дизайн вашого коду.
Якщо має сенс перевірити існування класу, добре, але якщо має сенс почекати, доки набір класів або плагінів завантажиться перед вашим власним, тоді субакції WordPress, ймовірно, мають більше сенсу.