Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
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

Russian (Pусский) translation by Yuri Yuriev (you can also view the original English article)

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

Вкратце то, чему вы можете научиться:

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

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

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

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

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

В частности мы будем говорить о концепции:

  • интерфейсы
  • Реализация интерфейса
  • принцип единственной ответственности
  • и других принципах и идеях, которые являются основной объектно-ориентированного программирования

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

С учетом сказанного, давайте приступим.

Приступая к работе

Как почти с каждым моим уроком, я хочу сделать две вещи:

  1. Определите план куда мы идем.
  2. Дать вам все, что нужно знать, чтобы привести ваш компьютер в рабочее состояние.

Давайте это сделаем, прежде чем мы перейдем к коду.

Наш план

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

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

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

Что нам необходимо

Для начала работы нам нужны следующие инструменты:

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

После этого мы готовы поговорить об интерфейсах и принципе единственной ответственности.

Определение Интерфейса

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

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

Может, есть более формальное определение? Конечно. Wikipedia предлагает:

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

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

Опять же, мы работаем с PHP. Что же на этот счёт говорится в учебнике the PHP manual ?

Интерфейсы объектов позволяют создавать код, который определяет, какие методы должен реализовать класс, без определения, как эти методы обрабатываются.

По моему мнению, это действительно хорошее определение. Это просто. Этот язык-агностик (как я это понимаю) работает с большинством (если не со всеми) объектно-ориентированных языков. Дальше в руководстве говорится:

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

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

  1. Мы определяем интерфейс почти как класс, но используем ключевое слово interface.
  2. Методы, определённые в интерфейсе, открыты (вместо protected или private), потому что это гарантирует функциональность, к которой могут получить доступ другие классы.

Как могут выглядеть интерфейсы в проекте WordPress? Вот пример из проекта, над которым я работаю:

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

Как мы все знаем, WordPress может учитывать и воспроизводить два типа активов: таблицы стилей и JavaScript файлы.

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

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

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

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

А вот то, как это создается и применяется через PHP, выходит за рамки данного руководства. Мы довольно этого увидим, когда начнём переделку нашего автозагрузчика.

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

Правило единой ответственности

Повод поговорить о принципе единой ответственности заключается в часто неправильном его истолковании, вроде:

Класс (или функция, или шаблон) должен делать одну и только одну вещь

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

Напротив, принцип гласит следующее:

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

Поскольку очень многие из нас, разработчиков, обращаются к Google за помощью в повседневной работе, то, я думаю, важно знать источник этой идеи. Она пришла от Uncle Bob Martin, как он общеизвестен или Robert Martin, автора некоторого числа top-shelf programming books.

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

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

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

  • Он определяет, пытается ли PHP вызвать код в этой функции.
  • Функция определяет, загружаем мы интерфейс или класс.
  • Затем автозагрузчик пытается включить файл или выдаёт ошибку.

Если класс должен иметь только одну причину для изменения, вот уже три причины (и это только на верхнем уровне), по которым эта единственная функция может измениться. Кроме того, код должен быть как можно яснее.

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

Объединение обоих вместе

Здесь интерфейсы и принцип единой ответственности должны начать работать рука об руку.

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

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

В нашем случае, я думаю, в этом есть смысл.

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

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

Заключение

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

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

Между тем, если вас интересуют материалы об объектно-ориентированном программировании в контексте WordPress, мои предыдущие уроки вы сможете найти на my profile page. Свободно заходите на on my blog или следуйте на мой Twitter, где я регулярно говорю на эти темы.

Как всегда, если ищете утилиты в дополнение к вашему набору инструментов развития для WordPress или примеры кода для обучения с целью стать более сведущим в WordPress, не забывайте заглянуть, что приготовлено на we have available in 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.