Если вы подходите к разработке многих плагинов WordPress с объектно-ориентированной точки зрения, то в конечном итоге вы достигнете точки, когда вы не будете много взаимодействовать непосредственно с самим ядром WordPress.
И, на мой взгляд, это хорошо. Это признак архитектуры, что вы правильно структурируете свой код. То есть:
- У вас есть WordPress на базовом уровне,
- У вас есть набор классов, которые находятся чуть выше WordPress и отвечают за отправку информации в WordPress и из него между плагином,
- И у вас есть остальная часть вашего кода, которая включает в себя остальную функциональность.
То, как это реализовано, может различаться, но в целом я представляю это так же, как я склонен думать о стандартном N-уровневом приложении, где у вас есть уровень данных, уровень приложения и внешний интерфейс.
За исключением этого времени, у вас есть WordPress, слой для связи с WordPress и остальная часть вашего кода, и, вы знаете, остальная часть вашего кода.
Как может быть организован плагин.
Итак, что происходит, когда вы хотите остановить выполнение плагина, когда он должен взаимодействовать со сторонней зависимостью и должен выполняться только в том случае, если эта зависимость присутствует?
Остановить выполнение плагина
Из-за особенностей PHP и WordPress это можно сделать несколькими способами. Код, которым я собираюсь поделиться, не предписывает, как это сделать.
Вместо этого это способ сделать это (который был взят из чего-то, что находится в разработке). Далее я покажу, как он взаимодействует с некоторыми другими компонентами плагинов.
1 Конструктор
Если вы прочитали достаточно статей о WordPress и объектно-ориентированном программировании, то, вероятно, обнаружите, что конструкторы не должны использоваться для определения хуков. И я согласен.
Это создает ненужный уровень связи и усложняет тестирование. Какова же цель конструктора в коде на основе WordPress?
Я использую его по тем же причинам, что и в любом другом языке: для инициализации свойств класса. В приведенном ниже коде вы увидите три вещи:
- Я инициализирую свойство,
- Я проверяю, существует ли сторонняя зависимость,
- Если это не так, я добавляю сообщение об ошибке,
- Я обновляю свойство.
Конечно, это многословно, но и не прибегает к умному коду для инициализации значений.
(Чем старше я становился, тем больше мне нравился конкретный код, поскольку его легче читать, усваивать и использовать быстрее, чем альтернативный код.)
2 Метод инициализации
Поскольку мы не используем конструктор для работы с хуками WordPress, эта функциональность должна существовать в контексте другого метода.
Это дает нам специальное место для размещения такого типа функциональности, отделяет его от остальной части класса и позволяет ему взаимодействовать с WordPress только при явном вызове метода.
Но помните, весь смысл того, что я имею в виду, связан с остановкой выполнения плагина, а не с размещением хуков.
Итак, допустим, что сторонней зависимости не существует, что тогда? Напомним, в конструкторе было задано свойство, которое позволит нам определить , стоит нам двигаться дальше с настройкой хуков или нет:
И когда это на месте, остальная часть кода не будет выполняться.
Много слов, мало кода
Звучит как много объяснений для такого очень маленького кода.
Но часть этого также предназначена для того, чтобы попытаться передать важность того, чтобы части проекта на основе WordPress были отделены от остальной части ядра, чтобы части могли взаимодействовать друг с другом без явной необходимости все время общаться с ядром.