Недавно я прошел процесс использования конструктора класса, чтобы предотвратить работу плагина, если ожидаемая зависимость не загружена.
Хотя я не считаю эту конкретную стратегию проблемой для одноразовой зависимости или в определенных ситуациях, есть способы, которыми это может привести к запахам кода.
Это также не позволяет нам использовать нативную функцию Core, называемую поддействиями WordPress:
https://twitter.com/JJJ/status/822265137935646720
Но прежде чем рассматривать поддействия, я хочу убедиться, что я четко понимаю проблемы, связанные с использованием условного подхода (в отличие от поддействий), которые могут породить запахи кода.
Вложенные действия WordPress
Есть много способов объяснить запахи кода, но мой любимый способ исходит от Мартина Фаулера :
…запахи — это определенные структуры в коде, которые указывают на нарушение фундаментальных принципов дизайна и негативно влияют на качество дизайна.
Есть еще одна замечательная страница о запахах кода на Source Making, которую я рекомендую прочитать, если у вас есть шанс.
И способ, которым условные операторы могут привести к запахам кода, прост: он потенциально может засорить ваш код огромным набором операторов, которые включают множество проверок class_exists.
И это проблема.
Каждый раз, когда вы вводите в свой код еще одну зависимость, вы в конечном итоге добавляете еще одну условную проверку, чтобы увидеть, присутствует ли класс в приложении WordPress.
Я считаю, что это нормально делать с одной зависимостью — может быть, даже с двумя зависимостями — и если вы работаете «достаточно высоко» в своей архитектуре, но это не то, как правильно обрабатывать это со многими зависимостями или на более низком уровне в ваш плагин.
Вот тут-то и появляются поддействия WordPress. Вы можете увидеть список поддействий в твите через Джона выше.
В Кодексе bbPress также есть официальное определение поддействий :
Эти внутренние действия можно рассматривать как «поддействия», и они позволяют вам добавлять или изменять порядок действий WordPress по мере необходимости для плагинов, зависящих от bbPress.
И вы можете увидеть пример этого в этом файле.
Конечно, это определение специфично для bbPress, но это не значит, что оно неприменимо к тому, что мы делаем в WordPress.
Показательный пример: если вы когда-либо использовали do_action для определения пользовательского действия или воспользовались хуком, предоставленным кем-то еще за пределами ядра WordPress, то вы знакомы со стратегией реализации поддействия.
Другими словами, поддействия WordPress — это просто действия, которые мы можем использовать для изменения порядка, в котором наш плагин зависит от другого плагина.
То, как это реализовано, может варьироваться в зависимости от контекста вашей работы, но самый популярный и самый «правильный» WordPress-способ сделать это, возможно, использовать аргумент приоритета при загрузке вашего плагина.
То есть возьмите приоритет зависимости и убедитесь, что он раньше, чем при активации вашего плагина.
Существуют альтернативные методы, которые можно использовать, например, изменение поведения плагинов независимо от того, активированы они или нет, но это выходит за рамки данного конкретного поста и может негативно повлиять на работу пользователя (в WordPress в целом, не меньше).
В любом случае, дело в том, что когда дело доходит до использования поддействий WordPress, объектно-ориентированного программирования и управления сторонними зависимостями, убедитесь, что принимаемые вами решения не повредят дизайну вашего кода.
Если есть смысл проверить существование класса, хорошо, но если имеет смысл подождать, пока набор классов или плагинов загрузится до того, как вы загрузите свой собственный, тогда поддействия WordPress, вероятно, будут иметь больше смысла.