Быстрое прототипирование с помощью WordPress: анализ концепции

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

Нет, это не аргумент в пользу того, почему объектная ориентация лучше. Это мой предпочтительный способ написания кода, поэтому я подхожу к этому именно так.

Я знаю, что пример кода, который я даю, прост, и я знаю, что можно сделать так, чтобы что-то подобное можно было оставить как есть. Но смысл этого в том, чтобы показать, как взять концепцию, создать ее прототип, а затем превратить ее во что-то, что следует объектно-ориентированным принципам.

И, по моему опыту, гораздо сложнее сделать это на сложном примере с самого начала. если вы потеряете читателей с самого начала, то какая надежда, что они поймут, что грядет?

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

Анализ концепции

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

И как только это работает, кажется, что мы закончили и можем перейти к следующей задаче. Но для крупных проектов это не всегда так. На самом деле, часто бывает лучше провести небольшой концептуальный анализ объектно-ориентированного анализа вашего проекта, прежде чем двигаться дальше.

Простое погружение в кодирование — не всегда лучший подход.

Дело для анализа

Показательный пример: на момент написания этой статьи один из моих товарищей по команде и я обсуждали, следует ли нам расширить класс или написать новый класс для обработки информации о геолокации для данных, извлеченных из API Карт Google.

Могу ли я запустить его и написать что-то, что работает? Конечно. Но будет ли он хорошо интегрироваться с приложением? Не обошлось без анализа концепции, планирования и координации с остальной частью системы.

И в этом заключается цель анализа.

Анализ нашей работы

Итак, что это означает для плагина, который мы рассмотрели вчера? На данный момент имеем следующее:

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

Кроме того, некоторые из этих функций связаны с хуками, которые являются частью WordPress API. А именно, функция создания метабокса привязана к WordPress, а сопутствующие функции для рендеринга отображения являются частью одного и того же компонента.

Затем у нас есть функции для запросов к базе данных, и у нас есть функции, непосредственно связанные с представлениями.

Итак, как это могло бы выглядеть, если бы мы разбили это на различные классы и файлы, которые помогли бы создать это более объектно-ориентированным образом?

Нет единого решения

Единого решения не существует, и некоторые решения намного более продвинуты, чем другие. Но поскольку я пытаюсь найти здесь баланс, я собираюсь подойти к этому проще, чем слишком много работать с абстракциями, наследованием, интерфейсами и всем этим.

Сосредоточенность на том, что у нас есть

А пока давайте сосредоточимся на отдельных классах и обязанностях, которые они могут выполнять. Например:

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

На данный момент наша диаграмма может выглядеть примерно так:

Разрушение метабокса.

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

Чтобы отобразить что-либо в мета-поле, нам нужен способ запросить базу данных для получения результатов. Оттуда нам нужно иметь возможность определить, есть ли результаты, если нет, а затем ввести эти результаты в представление.

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

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

Запрос к базе данных и подготовка сообщений.

Окончательная версия диаграммы может быть немного тесноватой, но в конечном итоге мы смотрим на что-то вроде этого:

Окончательная организация наших занятий.

В целях пояснения:

• Средство извлечения сообщений запрашивает у базы данных последние три самых последних сообщения.
• Почтовый мессенджер определит, какое сообщение выводить на дисплей.
• Дисплей отобразит установленное сообщение.
• Метабокс отобразит его в веб-браузере.

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

Преобразование в код

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

Обратите внимание, что то, как вы решите реализовать свой код или спроектировать свои классы, может немного отличаться от того, что я указал выше, и у вас могут быть предложения о том, как лучше организовать то, что указано выше. Если это так, оставьте комментарий.

В следующем посте мы рассмотрим преобразование этого в функциональный код, а после этого мы рассмотрим его организацию в правильные пространства имен и правильную организацию файлов.

Сообщения серии

1. Быстрое прототипирование с помощью WordPress: от концепции до плагина
2. Быстрое прототипирование с помощью WordPress: анализ концепции
3. Быстрое прототипирование: от прототипа к коду, часть 1
4. Быстрое прототипирование: от прототипа к коду, часть 2
5. Быстрое прототипирование: знакомство с автозагрузкой