Програмування WordPress: розділення проблем
Коли справа доходить до створення класів для плагінів WordPress, мене запитують, чому я поділяю функціональні можливості на передплатників та на інші класи.
Я думаю, що це гарне запитання, оскільки воно допомагає зрозуміти дві речі:
- роль передплатника щодо архітектури WordPress,
- роль інших класів у зв’язку з тим, що ви створюєте (і як це може допомогти з іншими речами, такими як модульне тестування тощо).
Тому я подумав, чому б не відповісти у формі короткого допису? Він задокументує, чому стоїть за тим, що [і це дасть мені місце для оновлення, якщо щось зміниться в майбутньому].
Я розглядаю класи, які не є об’єктами домену передплатників, які походять від підходу розробки програмного забезпечення до проектування, керованого доменом.
Це виходить за рамки цієї публікації, але варто згадати, якщо не з іншої причини, тому що це дає певний контекст тому, що інакше вважалося б жаргоном.
1 підписників
Але спочатку передплатники.
Оскільки WordPress базується на системі підхоплень – системі, яка заснована на шаблоні проектування, керованому подіями – корисно мати клас, який реагує на кожну подію.
Це може бути для будь-якого попередньо визначеного хука WordPress або будь-якого спеціального хука. Це не має значення.
І я не хочу ускладнювати клас, ніж потрібно, тому я думаю про них так:
Абонент відповідає щоразу, коли відбувається певна подія.
І це все. Ця подія може бути чимось на зразок after_theme_setup або the_content або навіть init. Це неважливо.
Він чекає на подію, а потім відповідає на те, що ми вирішимо, за допомогою іншого коду (де в гру вступають об’єкти домену).
Їх також можна назвати бізнес-об’єктами або щось подібне. Ідея, що стоїть за ними, така:
Усе, що ми робимо в об’єктно-орієнтованому програмуванні, має на меті розв’язати конкретну проблему, і це має на меті зробити це через певний тип об’єкта, який представляє об’єкт реального світу або принаймні конкретну ідею.
Тож щоразу, коли ви працюєте над тим, щоб надати рішення для когось, класи, які ви пишете – об’єкти, якими вони стануть після створення – є об’єктами домену.
Це також класи, які виконують фактичну роботу. Отже, ви можете розглядати це в трьох компонентах:
- WordPress. Звичайно, основна програма, яка викликає подію, на яку відповідають абоненти.
- Підписники. Набір класів, відповідальних за прослуховування певної події, а потім створення відповідного об’єкта для обробки коду.
- Об’єкти домену. Код, який фактично виконує роботу, беручи набір даних, оперуючи ним, а потім потенційно повертаючи значення.
Об’єкти домену – це місце, де живе код для фактичного виконання чогось. Підписники є зв’язком між WordPress і згаданою функціональністю.
Підписники кажуть: «Ця подія сталася, і цей клас здатний і відповідальний за обробку її результатів».
А як щодо тестування тощо?
Раніше в публікації я розповідав про те, як об’єкти домену пов’язані з модульним тестуванням та іншими методами програмування, пов’язаними з контролем якості.
Хоча це не публікація для подробиць, варто згадати, що збереження об’єктів домену та підписників відокремленими один від одного (і, у свою чергу, від WordPress) дозволяє нам створювати екземпляри, тестувати та працювати з об’єктами, які викликаються передплатників без необхідності залучати WordPress до нашої роботи.
І це те, що може бути надзвичайно корисним під час створення масштабних рішень. Але суть того, як це зробити, є вмістом для іншої публікації.