Простори імен і автозавантаження в WordPress

Минулого тижня я робив свою презентацію на WordCamp Atlanta про простори імен і автозавантаження. (повна назва була «Простори імен, автозавантаження та покращення архітектури плагінів», але це вже ковток, чи не так?)

Через характер розмови я вирішив написати публікацію, щоб супроводжувати публікацію, поділитися слайдами та прикладом плагіна GitHub, щоб допомогти підтримати розмову.

Отже, якщо ви були присутні, дякую(!) і ось публікація, я обіцяв. А для тих із вас, хто не був присутній, я сподіваюся, що ця публікація все ще допоможе продемонструвати концепції та теми, які я обговорював на WordCamp.

Простори імен і автозавантаження

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

Зрештою, чи багато хто з нас, розробників, уже задають питання:

Як ми можемо зробити наш код кращим, ніж він є?

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

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

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

По-перше, ваш код

Коли мова заходить про такі теми, як простори імен і автозавантаження в контексті WordPress, я думаю, що ми часто зустрічаємо неоднозначні відповіді.

Зрештою, ми могли б говорити про такі речі, як Theme Customizer або REST API, або щось цікавіше.

Я маю на увазі, що «простір імен і автозавантаження» просто не звучить захоплююче чи перспективне, якщо порівнювати його з новими функціями та технологіями, які доступні, чи не так?

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

Вони не нудні

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

«Все одно нудна розмова».

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

Отже, якщо ми так дбаємо про щось таке дрібне, ми, звичайно, дбаємо про ширшу картину. Такі речі, як:

• Покращений код
• Краща організація
• Підвищена ремонтопридатність
• Простіше налагодження
• Заробити більше грошей (ну, можливо).

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

Якби я підсумував простори імен ролей і місце автозавантаження у всьому вищесказаному, я б сказав, що:

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

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

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

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

Отже, що це таке?

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

Тож давайте на мить повернемося назад і розглянемо кожного окремо.

Простори імен

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

Ви встановлюєте його; ви активуєте його, а потім отримуєте принаймні один із таких:

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

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

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

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

Автонавантажувачі

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

• включати
• include_once
• вимагати
• вимагати_один раз

І іноді ви бачите їх у верхній частині файлу, який запускає плагін, а іноді ви бачите їх розкиданими по кодовій базі.

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

Автозавантаження може вирішити все це шляхом завантаження залежностей, коли це необхідно (і для тих, хто зацікавлений, автозавантаження швидше, ніж включення вручну).

Простори імен

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

Але після всього вищесказаного ви можете побачити переваги їх використання. Можливо, вони навіть веселі, чи не так? Може бути?

Незважаючи на це, нам потрібне визначення, на основі якого ми можемо працювати, обговорюючи це протягом решти статті.

У посібнику з PHP наведено таке визначення :

Простори імен призначені для вирішення двох проблем, з якими стикаються автори бібліотек і програм під час створення повторно використовуваних елементів коду, таких як класи або функції…

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

Може трохи краще?

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

У цій доповіді я не буду говорити про інтерфейси; однак я знаю, що є об’єктно-орієнтовані розробники середнього рівня, які їх використовують, тому я хотів переконатися, що принаймні згадаю про них.

Практичний приклад

Мені не подобаються приклади програмування, які не дають реального чи практичного застосування. Часто нам наводять приклади речей, які ми б ніколи не кодифікували.

Скільки разів ви читали об’єктно-орієнтовану статтю, і в ній наводиться приклад класу тварин або класу автомобіля? Ми не будемо програмувати автомобіль.

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

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

Отже, для нашого FileReader, можливо, основи класу виглядають так:

Клас для читання файлів.

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

А для FileWriter ми маємо щось на зразок цього:

Клас для запису файлів.

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

Знову ж таки, як у прикладі вище, це не включає перевірку помилок, запис через ресурс, закриття ресурсів тощо.

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

Примітки щодо просторів імен

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

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

Пам’ятайте:

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

Отже, давайте візьмемо код класів і простору імен.

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

Це означає, що тепер наш FileReader виглядатиме так:

Клас простору імен для читання файлів.

І наш FileWriter тепер виглядатиме так:

Клас простору імен для запису файлів.

По-перше, ви бачите, що використовувати простори імен легко: ви просто використовуєте ключове слово namespace, а потім оголошуєте простір імен (яким так само легко може бути WCATL) у верхній частині з наступними підпакетами.

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

Про організацію файлів

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

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

Невпорядковані файли

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

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

Ось тут і вступають у гру терміни «логічна організація» та «віртуальна організація».

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

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

Простори імен і автозавантаження: упорядковані файли

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

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

Примітки щодо просторів імен

Що відбувається, однак, коли нам потрібно створити екземпляри класів, які мають простір імен? Якщо класи не мають простору імен, легко використовувати ключове слово «новий».

Екземпляр без простору імен.

Але ми повинні створити екземпляр класу з простором імен, ми повинні зробити крок далі та використовувати повне ім’я:

Простори імен і автозавантаження: екземпляр із простором імен.

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

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

Звучить заплутано, чи не так? Можливо, побачити це в дії допоможе:

Псевдоніми просторів імен.

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

Автозавантаження

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

Незважаючи на це, найважливіші речі, які слід пам’ятати щодо просторів імен, на даний момент:

1. Простори імен — це спосіб групування споріднених класів та інтерфейсів, що мають подібне призначення.
2. Створіть парність у ваших файлах і просторах імен, переконавшись, що ваша логічна та віртуальна організація однакові.

А тепер настав час власне поглянути на автозавантаження.

Примітки щодо автозавантаження

По-перше, давайте розглянемо визначення автозавантаження, надане в посібнику PHP :

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

Це не погано. Однак це довго. Так само, як ми робили з просторами імен, давайте використаємо коротше визначення для цієї статті:

Спосіб автоматичного завантаження інтерфейсів і класів без використання операторів include і require.

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

Практичний приклад

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

1. ваші файли впорядковані,
2. ви готові їх завантажити

Тож час зробити це автоматично, чи не так? Але тут є заковика. Ціле «автоматичне завантаження» файлів вимагає трохи роботи.

Написання автозавантажувача

Тобто це автоматично, але все одно вимагає трохи більше роботи з нашого боку. Перш ніж переходити до цих кроків, важливо зауважити:

1. це не повністю автоматизовано,
2. ми повинні це написати.

Як би добре не було, щоб код завантажувався автоматично, ми повинні прочитати деякі дані, проаналізувати їх, а потім спробувати завантажити відповідний файл.

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

Кроки для автозавантажувача

Під час написання автозавантажувача потрібно виконати лише кілька кроків. Автозавантажувач повинен відповідати на такі файли:

1. Де файли?
2. Як вони називаються?
3. Файл існує?

Якщо все вищезазначене вірно (або ви можете відповісти «так» на всі), то автозавантажувач буде робити те, що він повинен робити.

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

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

Ось перша частина коду. Я поясню, що він робить постфактум:

Автозавантаження, частина 1 – Пошук класу

У цій частині коду функція отримує повне ім’я класу, який потрібно створити (наприклад, «WCATLFileFileReader()»).

Далі він розділяє всі частини повного імені на частини. Ім’я класу є останнім індексом масиву, і я вирішив назвати свої файли «class-filereader.php», тому функція створює змінну $class_file, яка посилається на ім’я файлу.

Але ми ще не закінчили. Нам ще потрібно отримати повне ім’я (тобто місце розташування файлу на диску). Це може виглядати приблизно так:

Автозавантаження, частина 2 – отримання повного імені

На цьому етапі ми готуємо змінну $fully_qualified_path, яка посилатиметься на каталог верхнього рівня.

Далі код перебирає всі індекси масиву та створює шлях до файлу класу. Ви можете уявити це як створення рядка, такого як “wcatlfile", який ми потім об’єднуємо з $class_file.

Це означає, що повний шлях до файлу стає «wcatlfileclass-filereader.php».

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

Якщо файл не існує, є кілька варіантів:

1. Створити виняток,
2. Спіймати виняток,
3. Відобразити власне повідомлення про помилку,
4. Або інший варіант, який я, можливо, розгляну в цій статті.

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

На автозавантаженні

Перш ніж завершити, важливо звернути увагу на наступне:

• У цьому прикладі ми використовували об’єктно-орієнтований код, розміщуючи код у просторі імен. Зрештою, це об’єктно-орієнтована концепція.
• Наш автозавантажувач написаний у процедурному коді. Що дає?

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

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

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

Ресурси (і дякую!)

Це одна з найдовших статей, які я написав для свого сайту.

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

Окрім цієї статті, я також надав такі ресурси:

• Слайди моєї презентації доступні на SpeakerDeck.
• У мене є код із цієї презентації, який можна завантажити на GitHub.

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