Якщо ви не читали першу публікацію з цієї серії, я рекомендую її, оскільки ми починаємо писати об’єктно-орієнтований код для WordPress за допомогою API віджетів.
Серія збирається зафіксувати кілька речей:
- покаже вам базовий скелет віджета та чому він об’єктно-орієнтований,
- обговоріть, які речі ви повинні вміти помічати і чому
- спочатку оновіть Widget Boilerplate безпосередньо на цьому сайті, а потім надішліть його на GitHub,
- створити віджет за допомогою API із шаблоном як основою для нашої роботи.
Але перед тим, як це зробити, я хочу переконатися, що кожен, хто читає це, знає основні принципи об’єктно-орієнтованого програмування та має все необхідне для створення об’єктно-орієнтованого рішення для WordPress.
З цією метою я рекомендую наступне:
- Два стовпи об’єктно-орієнтованого програмування: частина 1 з 2
- Два стовпи об’єктно-орієнтованого програмування: Частина 2 із 2
- Абстрактні заняття, частина 1 – Абстрагування поведінки
- Абстрактні класи, частина 2 – Абстрактні класи та інтерфейси
- Незалежний розробник WordPress
Якщо ви прочитали весь цей вміст, чудово. Ви будете добре підготовлені до цієї та наступних публікацій. Якщо ні, у решті того, що ви збираєтеся прочитати, можуть бути певні прогалини, але суть публікації має бути достатньо зрозумілою.
У чому саме справа?
Ось що: минулого тижня я поділився частиною коду разом із деякою інформацією про API віджетів. Я збираюся переглянути це трохи більше в цій публікації, перш ніж ми перейдемо до більш інтенсивної частини кодування з двох причин:
- Я хочу, щоб усі, хто читає це, були на одній сторінці щодо написання об’єктно-орієнтованого коду (принаймні, у цьому контексті),
- Я розумію, що люди мають різне походження, і я хочу переконатися, що ми всі якомога більше на одній сторінці, перш ніж продовжити.
Якщо у вас є досвід написання об’єктно-орієнтованого коду, особливо на просунутому рівні, це може здатися вам простішим; в іншому випадку я сподіваюся, що це озброїть вас усім необхідним для виявлення об’єктно-орієнтованих практик не лише щодо цього API, але й під час читання чужого коду.
Як виявити об’єктно-орієнтоване програмування
Можливо, перше запитання полягає в тому, чому нам потрібно вміти виявляти, читати або розуміти об’єктно-орієнтоване програмування, перш ніж його писати?
Кілька слів про поганий код
Коротка відповідь на це:
Вам не потрібно, але мені це корисно. Якщо ви вмієте читати об’єктно-орієнтоване програмування, ви матимете перевагу в тому, щоб скористатися перевагами того, що воно пропонує як парадигму, оскільки ви збираєтеся спиратися на стратегії та роботу, виконану іншими в інших проектах.
Це не означає, що ми не будемо читати поганий код, але ми зробимо все можливе, щоб виявити поганий код, визначити проблемні області, а потім зробити все можливе, щоб уникнути його включення в нашу роботу.
А поки що давайте розглянемо API віджетів, щоб побачити, що ми можемо зробити для виявлення об’єктно-орієнтованого програмування.
Назад до об’єктно-орієнтованого програмування
У попередній публікації я описав дві речі, які вказують на об’єктно-орієнтований API (принаймні певною мірою):
- використання ключового слова extends ,
- функції, які ми повинні реалізувати.
Причина, чому я хочу повернутися до цієї теми, полягає в тому, що вона визначає дві ключові речі, які є частиною основних об’єктно-орієнтованих принципів: успадкування та реалізація функції (яка часто є частиною абстрактних класів ).
Примітка, перш ніж ми подивимося на вищесказане:
Коли ви подивіться на джерело класу WP_Widget, ви помітите, що там немає абстрактних методів. Але деякі функції, які ми повинні реалізувати, про які я згадаю пізніше в цій публікації, є основними кандидатами на абстрактні методи. І я також обговорю чому.
Давайте розділимо наведені вище теми на два окремі розділи: Наслідування та Абстракції.
Спадщина
У попередній публікації я розповів про відносну глибину успадкування, тому не буду розголошувати цю тему тут. Я запропоную кілька слів, але я набагато більше зацікавлений в обговоренні абстракції, що я зроблю це за мить.
Перш ніж заходити занадто далеко в це, будь ласка, зверніться до наступного коду:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Але по-перше, ми можемо визнати, що будь-який клас, який реалізує Widgets API, повинен використовувати успадкування просто через ключове слово extends.
Це означає, що є рівень функціональності, який ми збираємося успадкувати (або отримати безкоштовно), і є рівень функціональності, який ми повинні реалізувати самостійно.
З посібника PHP :
Наприклад, коли ви розширюєте клас, підклас успадковує всі загальнодоступні та захищені методи від батьківського класу. Якщо клас не замінить ці методи, вони збережуть свою оригінальну функціональність.
Проте коли ви успадковуєте функціональність від класу, ви можете виявити, що важливо строго викликати конструктор батьківського класу (у нашій функції __construct ).
Але це піднімає, на мою думку, одну з найважливіших проблем із успадкуванням у PHP (і вся причина, чому я хотів включити цей розділ): чи потрібно нам явно викликати батьківський конструктор?
Також згідно інструкції:
Батьківські конструктори не викликаються неявно, якщо дочірній клас визначає конструктор. Щоб запустити батьківський конструктор, потрібен виклик parent::__construct() у дочірньому конструкторі. Якщо дочірній елемент не визначає конструктор, він може бути успадкований від батьківського класу так само, як звичайний метод класу (якщо він не був оголошений як приватний).
Але ми можемо це спростити. Можливо, це легше запам’ятати:
- Якщо наш клас використовує успадкування, але не визначає конструктор, викликається батьківський конструктор.
- Якщо наш клас використовує успадкування, але визначає конструктор, батьківська конструкція має бути викликана явно.
Або, можливо, ще простіше:
- Якщо наш клас не визначає конструктор, код за умовчанням буде конструктором батьків.
Мати сенс? Якщо коротко, якщо ми визначаємо наші властивості, ініціалізацію та код у конструкторі, перший рядок конструктора нашого класу має бути викликом батьківського конструктора.
Абстракція
Щоб бути абсолютно зрозумілим, вихідний код класу WP_Widget не містить абстрактних методів. Частково це пов’язано з тим, як створено клас, частково – із зворотною сумісністю та функціями PHP5.
Однак це не означає, що ми не можемо визначити, які функції можна позначити як абстрактні. Фактично, я вважаю, що це визначає, які класи слід зробити абстрактними. Але спочатку давайте визначимо абстрактні функції.
При успадкуванні від абстрактного класу всі методи, позначені як абстрактні в декларації батьківського класу, повинні бути визначені дочірнім; крім того, ці методи повинні бути визначені з однаковою (або менш обмеженою) видимістю.
Дивлячись на джерело нашого віджета:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Я вважаю справедливим сказати, що функцію форми можна позначити як абстрактну, оскільки вона унікальна для нашої реалізації. Інший спосіб думати про абстрактні функції з точки зору програмування — запитати себе: які функції вимагатимуть унікальної функціональності?
І в цьому випадку функція форми є саме такою, оскільки кожен віджет унікально відрізнятиметься від того, що він відображає. Функцію віджета також можна позначити як абстрактну, оскільки вона виводить вміст віджета. Цей вміст, природно, базується на функціональності, яку ми реалізували в нашій реалізації.
Крім того, вихідний код самого класу WP_Widget каже:
функція WP_Widget::widget() має бути замінена в підкласі.’
Це саме той тип функції, який слід позначати як абстрактний. Оскільки PHP видасть помилку, якщо функцію позначено як абстрактну та не реалізовано. Нам не потрібні були жодні виклики функцій die чи щось подібне.
Однак інші функції не обов’язково потрібно позначати як абстрактні, і ось чому:
- __construct викличе батьківський конструктор на самому базовому рівні, і це необхідно для ініціалізації базового класу. Однак не забувайте; ми можемо додати наші властивості до цього методу, які є унікальними для нашого класу.
- update використовує функціональність у батьківському класі для серіалізації інформації.
Таким чином, ми залишилися з двома функціями, які можна позначити як абстрактні в більш сучасній ітерації класу.
Далі
На цьому етапі ми всі повинні бути на одній сторінці, що стосується об’єктно-орієнтованого коду. Принаймні, наскільки ми можемо ознайомитися з серією публікацій у блозі.
Починаючи з наступної публікації, ми повернемося до написання коду.
Тобто ми переглянемо шаблон віджетів WordPress, і я збираюся відредагувати його в його поточному стані, щоб прийняти більш сучасні стандарти PHP.
Я збираюся поділитися змінами, які я роблю, обґрунтуванням, чому, а потім я також розповім про тип віджета, який ми збираємося створити на основі шаблону (і ми можемо це зробити).