Швидке створення прототипів за допомогою WordPress: аналіз концепції

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

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

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

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

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

Аналіз концепції

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

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

Просто перейти до кодування – не завжди найкращий підхід.

Випадок для аналізу

Приклад: під час написання цієї статті ми з одним із моїх товаришів по команді обговорювали, чи слід нам розширити клас або написати новий клас для обробки інформації про геолокацію для даних, отриманих з API Карт Google.

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

І саме в цьому полягає мета аналізу.

Аналізуємо нашу роботу

Отже, що це означає для плагіна, який ми розглядали вчора? Зараз ми маємо наступне:

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

Крім того, деякі з цих функцій пов’язані з хуками, які є частиною API WordPress. Зокрема, функція для створення метабокса підключена до WordPress, а її супутня функція для рендерингу дисплея є частиною одного компонента.

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

Отже, як би це виглядало, якби ми розділили це на різні класи та файли, які допомогли б створити це більш об’єктно-орієнтованим способом?

Немає єдиного рішення

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

Зосередження на тому, що ми маємо

А поки що зосередимося на окремих заняттях і обов’язках, які вони можуть виконувати. Наприклад:

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

На цьому етапі наша діаграма може виглядати приблизно так:

Розбиття метабокса.

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

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

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

Можливо, один із способів організації занять виглядав би так:

Запит до бази даних і підготовка повідомлень.

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

Остаточна організація наших занять.

Для цілей пояснення:

• Система отримання повідомлень запитує в базі даних три останні останні публікації.
• Поштовий месенджер визначить, яке повідомлення вставити на дисплей.
• На дисплеї відобразиться встановлене повідомлення.
• Мета поле відображатиметься у веб-браузері.

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

Перетворення на код

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

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

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

Повідомлення серії

1. Швидке створення прототипів за допомогою WordPress: від концепції до плагіна
2. Швидке створення прототипів за допомогою WordPress: аналіз концепції
3. Швидке створення прототипів: прототип до коду, частина 1
4. Швидке створення прототипів: прототип до коду, частина 2
5. Швидке створення прототипів: представлення автозавантаження