Advertisement
  1. Code
  2. WordPress Plugins

Об'єктно-орієнтоване автоматичне завантаження в WordPress - Частина 1 

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Object-Oriented Autoloading in WordPress.
Object-Oriented Autoloading in WordPress, Part 2

Ukrainian (українська мова) translation by Григорий В (you can also view the original English article)

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

Коротенько то, чого ви можете навчитися: 

У цій серії ми розглянемо, що ж таке простору імен PHP, чим вони корисні і як їх використовувати.  Потім ми розглянемо використання Автозавантажувач для автоматичного завантаження файлів, без необхідності вручну завантажувати їх в наш код. 

Під час роботи на цій серії, особливо про автозавантажувач, я не міг не звернути увагу на деякі недоліки коду, який я описував. 

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

Але в серії, яка зосереджена на просторах імен - що є невід'ємною частиною об'єктно-орієнтованого програмування - я не міг залишити автозавантажувач в його остаточному вигляді. 

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

Зокрема мова йтиме про: 

  • інтерфейси 
  • реалізацію інтерфейсу 
  • принцип єдиної відповідальності 
  • і іншi принципi і ідеї, які є основою об'єктно-орієнтованого програмування 

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

З урахуванням сказаного, давайте приступимо. 

Приступаючи до роботи 

Як майже з кожним моїм уроком, я хочу зробити дві речі: 

  1. Визначте план куди ми йдемо. 
  2. Дати вам все, що потрібно знати, щоб привести ваш комп'ютер в робочий стан. 

Давайте це зробимо, перш ніж ми перейдемо до коду. 

Наш план 

Протягом наступних двох уроків ми розглянемо деякі об'єктно-орієнтовані концепції, за допомогою яких ми вдосконалюємо плагін, який ми написали в попередніх уроках. 

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

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

Що нам необхідно 

Для початку роботи нам потрібні такі інструменти: 

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

Після цього ми готові поговорити про інтерфейси та принципі єдиною відповідальності.

Визначення інтерфейсу 

Залежно від вашого досвіду програмного забезпечення, коли ви чуєте слово «інтерфейс», ви можете подумати, що інтерфейс - це те, що насправді бачить користувач на екрані.  Ви знаєте: інтерфейс користувача

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

Може, є більш формальне визначення?  Звичайно.  Wikipedia пропонує: 

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

Непогано сказано.  Досить загальний текст, щоб застосувати його до будь-якої мови програмування і не такий технічний, щоб не можна було його зрозуміти. 

Знову ж таки, ми працюємо з PHP.  Що ж на цю тему йдеться в підручнику the PHP

Інтерфейси об'єктів дозволяють створювати код, який визначає, які методи повинен реалізувати клас, без визначення, як ці методи обробляються. 

На мою думку, це дійсно гарне визначення.  Це просто.  Ця мова-агностик (як я це розумію) працює з більшістю (якщо не з усіма) об'єктно-орієнтованих мов.  Далі в керівництві говориться: 

Інтерфейси визначаються таким же чином, як клас, але з заміною ключового слова class ключовим словом interface і без будь-яких методів визначення їх вмісту. 
Всі методи, оголошені в інтерфейсі, повинні бути відкритими; це в природі інтерфейсу. 

Це дві умови, про які ми повинні пам'ятати, якщо збираємося виконувати власні інтерфейси, особливо коли справа стосується цього плагіна.  А саме, ми повинні запам'ятати наступне: 

  1. Ми визначаємо інтерфейс майже як клас, але використовуємо ключове слово interface
  2. Методи, певні в інтерфейсі, відкриті (замість protected або private), тому що це гарантує функціональність, до якої можуть отримати доступ інші класи. 

Як можуть виглядати інтерфейси в проекті WordPress?  Ось приклад з проекту, над яким я працюю:

З цього коду зрозуміло, яким цілям він служить, особливо з огляду на коментар, який сидить над інтерфейсом.

Як ми всі знаємо, WordPress може враховувати і відтворювати два типи активів: таблиці стилів і JavaScript файли. 

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

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

У всякому разі, будь-який клас, який реалізує цей інтерфейс, зобов'язаний надати функціональність для наступних методів.  Так як же виглядає клас, який реалізує цей інтерфейс? 

Ось дуже простий приклад класу, який додає таблицю стилів в адміністративну панель WordPress: 

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

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

Правило єдиної відповідальності 

Привід поговорити про принцип єдиної відповідальності полягає в часто неправильному його тлумаченні, на кшталт: 

Клас (або функція, або шаблон) повинен робити одну і тільки одну річ.

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

Навпаки, принцип говорить наступне: 

Клас повинен мати тільки одну причину для зміни. 

Оскільки дуже багато хто з нас, розробників, звертаються до Google за допомогою в повсякденній роботі, то, я думаю, важливо знати джерело цієї ідеї.  Вона прийшла від Uncle Bob Martin, як він загальновідомий або Robert Martin, автора деякого числа кращих книг з програмування.

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

Розглянемо код (я знаю, це не клас, це функція, але принцип можна застосувати): 

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

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

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

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

Об'єднання обох разом

Тут інтерфейси і принцип єдиної відповідальності повинні почати працювати рука об руку. 

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

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

У нашому випадку, я думаю, в цьому є сенс. 

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

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

Висновок 

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

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

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

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

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

Ресурси 

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.