Часть 4 — WordPress и объектно-ориентированное программирование: пример WordPress — дизайн

На данный момент у нас есть четко определенные требования, как они были описаны в части 3 этой серии (проверьте это здесь, если вы пропустили это).

Настало время подумать о дизайне нашего нового улучшенного плагина!

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

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

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

Анализ страницы настроек

Давайте подробнее рассмотрим страницу администратора плагина.

Вы заметите, что в нижней части страницы есть заголовок («Настройки ограничения попыток входа»), несколько разделов, содержащих несколько полей, и кнопка «Изменить параметры».

Каждый раздел состоит из заголовка, например «Статистика», и нескольких полей.

Каждое поле имеет заголовок слева, а остальную часть его содержимого — справа. Есть текстовые поля, переключатели и флажки, а некоторые из них, например «Total Lockouts», только отображают информацию и не могут быть изменены пользователем-администратором напрямую.

Некоторые поля также содержат описание, например поле «Подключение к сайту», но не все из них.

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

API настроек WordPress позволяет нам регистрировать страницы настроек, разделы на этих страницах и поля внутри разделов:

Страницы → Разделы → Поля

Мы подумали, почему бы не добавить еще один «слой», Элементы, чтобы упростить расширение нашего плагина в будущем.

Страницы → Разделы → Поля → Элементы

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

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

В будущем нам также может понадобиться добавить больше страниц и разделов. Поэтому вполне вероятно, что нам потребуется расширить эти классы страниц администратора и разделов.

То же самое касается полей. Классы для «Полных блокировок», «Активных блокировок» и т. д. будут расширять тот же (родительский) класс.

Вот упрощенное изображение, демонстрирующее эти отношения:

Конечно, не все «компоненты» включены в схему.

Подобная структура упрощает расширение плагина; мы можем легко добавить поле, элемент или раздел, если возникнет такая необходимость. Мы сможем легко добавлять дополнительные компоненты — поля, элементы или разделы — путем создания новых дочерних классов без необходимости изменять существующие.

Мышление и абстрагирование

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

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

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

Обратите внимание на то, что пользовательский интерфейс реализуется классами Statistics, Lockout Logs, Table и Element, которые называются родительскими классами. В классах Radio/Number/Checkbox Element нет необходимости напрямую реализовывать интерфейс, поскольку они наследуют все интерфейсы от своего родительского класса. Однако дочерний класс может переопределить метод своего родительского класса.

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

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

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

Основной файл плагина

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

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

Возможные классы

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

• Повторные попытки
• Блокировки
• Печенье
• Сообщения об ошибках
• Уведомления по электронной почте
• Уведомления администратора
• Кнопки
• Журналы блокировки
• Активные/полные блокировки
• айпи адрес

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

В разделе «Общие», например, отношения между нашими классами будут выглядеть так:

Раздел «Статистика» будет выглядеть примерно так:

Наконец, «Журналы блокировки» будут очень похожи на «Статистика»:

Вывод

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

Нажмите здесь, чтобы прочитать часть 5 в нашей серии объектно-ориентированного программирования

Смотрите также

• WordPress и объектно-ориентированное программирование — обзор
• Часть 2 — WordPress и объектно-ориентированное программирование: пример из реальной жизни
• Часть 3 — WordPress и объектно-ориентированное программирование: пример WordPress — определение области