Если вы не читали первый пост в этой серии, я рекомендую его, так как мы начинаем писать объектно-ориентированный код для WordPress с помощью API виджетов.
Сериал собирается захватить несколько вещей:
- показать вам основной скелет виджета и почему он объектно-ориентированный,
- обсудите, какие вещи вы должны уметь замечать и почему
- сначала обновите Widget Boilerplate непосредственно на этом сайте, а затем отправьте его на GitHub,
- создайте виджет, используя API с шаблоном в качестве основы для нашей работы.
Но прежде чем сделать это, я хочу убедиться, что все, кто читает это, усвоили основные принципы объектно-ориентированного программирования и имеют все необходимое для создания объектно-ориентированного решения для WordPress.
С этой целью я рекомендую следующее:
- Два столпа объектно-ориентированного программирования: часть 1 из 2
- Два столпа объектно-ориентированного программирования: часть 2 из 2
- Абстрактные классы, часть 1 – абстрагирующее поведение
- Абстрактные классы. Часть 2. Абстрактные классы и интерфейсы
- Независимый разработчик WordPress
Если вы прочитали весь этот контент, отлично. Вы будете хорошо подготовлены к этому посту и следующим постам. Если нет, то в остальной части того, что вы собираетесь прочитать, могут быть пробелы, но суть поста должна быть достаточно ясной.
В чем дело, точно?
Вот в чем дело: на прошлой неделе я поделился небольшим количеством кода вместе с некоторой информацией об API виджетов. Я собираюсь вернуться к этому немного больше в этом посте, прежде чем мы перейдем к более интенсивной части кодирования по двум причинам:
- Я хочу, чтобы все, читающие это, были на одной странице, поскольку это относится к написанию объектно-ориентированного кода (по крайней мере, в этом контексте),
- Я понимаю, что люди приходят из разных слоев общества, и я хочу убедиться, что мы все на одной волне, прежде чем продолжить.
Если у вас есть опыт написания объектно-ориентированного кода, особенно в расширенном объеме, это может показаться вам более простым; в противном случае я надеюсь, что это вооружит вас всем необходимым для обнаружения объектно-ориентированных практик не только в отношении этого API, но и при чтении чужого кода.
Как обнаружить объектно-ориентированное программирование
Возможно, первый естественный вопрос: зачем нам нужно уметь обнаруживать, читать или понимать объектно-ориентированное программирование, прежде чем его писать?
Несколько слов о плохом коде
Краткий ответ на это таков:
Вам не нужно, но мне это полезно. Если вы умеете разбираться в объектно-ориентированном программировании, у вас будет преимущество в использовании того, что оно предлагает в качестве парадигмы, потому что вы будете опираться на стратегии и работу, проделанную другими в других проектах.
Это не означает, что мы не будем читать плохой код, но мы сделаем все возможное, чтобы идентифицировать плохой код, определить проблемные области, а затем сделать все возможное, чтобы избежать включения его в нашу работу.
А пока давайте взглянем на Widgets API, чтобы увидеть, что мы можем сделать для обнаружения объектно-ориентированного программирования.
Назад к объектно-ориентированному программированию
В предыдущем посте я обозначил две вещи, указывающие на то, что API является объектно-ориентированным (по крайней мере, до некоторой степени):
- использование ключевого слова extends ,
- функции, которые мы должны реализовать.
Причина, по которой я хочу вернуться к этой теме, заключается в том, что в ней определены две ключевые вещи, являющиеся частью основных принципов объектно-ориентированного программирования: наследование и реализация функций (которые часто являются частью абстрактных классов ).
Примечание, прежде чем мы рассмотрим вышеизложенное:
Когда вы посмотрите на исходный код класса WP_Widget, вы заметите, что в нем нет абстрактных методов. Но некоторые из функций, которые мы должны реализовать, о которых я упомяну позже в этом посте, являются первыми кандидатами на роль абстрактных методов. И я также расскажу, почему.
Давайте разделим темы выше на два отдельных раздела: Наследование и Абстракции.
Наследование
Я рассмотрел наследование как относительную глубину в предыдущем посте, поэтому не буду здесь останавливаться на этом. Я скажу несколько слов, но меня гораздо больше интересует обсуждение абстракции, чем я и займусь через минуту.
Прежде чем углубляться в это, пожалуйста, обратитесь к следующему коду:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Но сначала мы можем понять, что любой класс, реализующий Widgets API, должен использовать наследование просто из-за ключевого слова extends.
Это означает, что есть уровень функциональности, который мы унаследуем (или получим бесплатно), и есть уровень функциональности, который мы должны реализовать самостоятельно.
Из руководства по PHP :
Например, когда вы расширяете класс, подкласс наследует все общедоступные и защищенные методы родительского класса. Если класс не переопределит эти методы, они сохранят свою первоначальную функциональность.
Однако, когда вы наследуете функциональность от класса, вы можете обнаружить, что важно строго вызывать родительский конструктор (в нашей функции __construct ).
Но это поднимает то, что я считаю одним из самых важных вопросов наследования в PHP (и именно поэтому я хотел включить этот раздел): нужно ли нам явно вызывать родительский конструктор?
Также по мануалу:
Родительские конструкторы не вызываются неявно, если дочерний класс определяет конструктор. Чтобы запустить родительский конструктор, требуется вызов parent::__construct() внутри дочернего конструктора. Если дочерний элемент не определяет конструктор, он может быть унаследован от родительского класса точно так же, как обычный метод класса (если он не был объявлен как закрытый).
Но мы можем упростить это. Возможно, это легче запомнить:
- Если наш класс использует наследование, но не определяет конструктор, вызывается родительский конструктор.
- Если наш класс использует наследование, но определяет конструктор, родительская конструкция должна вызываться явно.
Или, может быть, еще проще:
- Если наш класс не определяет конструктор, код по умолчанию будет использовать родительский конструктор.
Есть смысл? Короче говоря, если мы определяем наши свойства, инициализацию и код в конструкторе, первая строка конструктора нашего класса должна быть вызовом родительского конструктора.
Абстракция
Для полной ясности: исходный код класса WP_Widget не содержит абстрактных методов. Частично это связано с тем, как построен класс, частично с обратной совместимостью и функциями PHP5.
Однако это не означает, что мы не можем определить, какие функции можно пометить как abstract. На самом деле, я думаю, это говорит о том, какие классы следует сделать абстрактными. Но сначала давайте определим абстрактные функции.
При наследовании от абстрактного класса все методы, помеченные как абстрактные в объявлении родительского класса, должны быть определены дочерним; кроме того, эти методы должны быть определены с такой же (или менее ограниченной) видимостью.
Глядя на источник нашего виджета:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Я думаю, будет справедливо сказать, что функция формы может быть помечена как абстрактная, потому что она уникальна для нашей реализации. Другой способ думать об абстрактных функциях с точки зрения программирования — спросить себя: какие функции потребуют уникальной функциональности?
И в этом случае функция формы именно такова, потому что каждый виджет будет уникально отличаться в зависимости от того, что он отображает. Функцию виджета также можно пометить как абстрактную, поскольку она выводит содержимое виджета. Этот контент, естественно, основан на функциональности, которую мы реализовали в нашей реализации.
Кроме того, исходный код самого класса WP_Widget говорит:
функция WP_Widget::widget() должна быть переопределена в подклассе».
Это именно тот тип функции, который следует помечать как абстрактный. Потому что PHP выдаст ошибку, если функция помечена как абстрактная и не реализована. Нам не нужны были вызовы функций die или что-то в этом роде.
Однако другие функции не обязательно должны быть помечены как абстрактные, и вот почему:
- __construct вызовет конструктор родителя на самом базовом уровне, и это необходимо для инициализации базового класса. Не забывайте, однако; мы можем добавить к этому методу свои свойства, уникальные для нашего класса.
- update использует функциональные возможности родительского класса для сериализации информации.
Таким образом, у нас остались две функции, которые можно было бы пометить как абстрактные в более современной итерации класса.
Следующий
На данный момент мы все должны быть на одной странице, поскольку это относится к объектно-ориентированному коду. По крайней мере, насколько мы можем пройти через серию сообщений в блоге.
Начиная со следующего поста, мы вернемся к написанию кода.
То есть мы вернемся к WordPress Widget Boilerplate, и я собираюсь провести его рефакторинг в его текущем состоянии, чтобы принять более современные стандарты PHP.
Я собираюсь поделиться изменениями, которые я вношу, обоснованиями того, почему, а затем я также расскажу о типе виджета, который мы собираемся создать на основе шаблона (и мы можем это сделать).