Программирование WordPress: разделение проблем
Когда дело доходит до создания классов для плагинов WordPress, меня спрашивают, почему я разделяю функциональность на подписчиков и другие классы.
Я думаю, что это хороший вопрос, потому что он помогает понять две вещи:
- роль подписчика в отношении архитектуры WordPress,
- роль других классов в отношении того, что вы создаете (и как это может помочь с другими вещами, такими как модульное тестирование и т. д.).
Вот я и подумал, почему бы не ответить в виде короткого поста? В нем будет документировано, почему за чем [и это даст мне место для обновления, если что-то изменится в будущем].
Программирование WordPress: подписчики и объекты домена
Я рассматриваю классы, не являющиеся объектами домена подписчиков, которые исходят из подхода к разработке программного обеспечения, основанного на проектировании, управляемом доменом.
Это выходит за рамки этого поста, но стоит упомянуть хотя бы по той причине, что он дает некоторый контекст тому, что в противном случае считалось бы жаргоном.
1 подписчиков
Но сначала подписчики.
Поскольку WordPress основан на системе ловушек — системе, основанной на шаблоне проектирования, управляемом событиями, — полезно иметь класс, который реагирует на каждое событие.
Это может быть любой предопределенный хук WordPress или любой пользовательский хук. Не имеет значения.
И я не хочу делать класс более сложным, чем необходимо, поэтому я склонен думать о них так:
Подписчик отвечает всякий раз, когда происходит определенное событие.
Вот и все. Это событие может быть чем-то вроде after_theme_setup , the_content или даже init. Это не имеет значения.
Он ждет, когда произойдет событие, а затем реагирует на то, что мы решаем, используя другой код (именно здесь в игру вступают объекты предметной области).
2 объекта домена
Их также можно назвать бизнес-объектами или чем-то подобным. Идея, стоящая за ними, заключается в следующем:
Все, что мы делаем в объектно-ориентированном программировании, предназначено для решения конкретной проблемы, и оно предназначено для этого через некоторый тип объекта, который представляет объект реального мира или, по крайней мере, конкретную идею.
Поэтому всякий раз, когда вы работаете над предоставлением решения для кого-то, классы, которые вы пишете — объекты, которыми они станут при создании экземпляров — являются объектами предметной области.
Это также классы, которые выполняют реальную работу. Таким образом, вы можете думать об этом в трех компонентах:
- Вордпресс. Основное приложение, конечно же, вызывает событие, на которое реагируют подписчики.
- Подписчики. Набор классов, отвечающих за прослушивание определенного события и последующее создание экземпляра соответствующего объекта для обработки кода.
- Объекты домена. Код, который на самом деле выполняет работу по приему набора данных, работе с ним и потенциальному возврату значения.
Объекты предметной области — это место, где живет код для реального выполнения чего-либо. Подписчики похожи на связь между WordPress и указанной функциональностью.
Подписчики говорят: «Это событие произошло, и этот класс способен и отвечает за обработку его результатов».
Как насчет тестирования и так далее?
Ранее в этом посте я говорил о том, как объекты предметной области связаны с модульным тестированием и другими методами программирования, связанными с контролем качества.
Хотя это не статья для подробностей, стоит упомянуть, что хранение объектов домена и подписчиков отдельно друг от друга (и, в свою очередь, от WordPress) позволяет нам создавать экземпляры, тестировать и работать с объектами, которые вызываются подписчиков без необходимости использовать WordPress в нашей работе.
И это то, что может быть очень полезно при создании более крупных решений. Но суть того, как это сделать, содержится в другом посте.