В WordPress можно встретить множество стилей программирования. Это огромный мир, который вмещает в себя разные стили и подходы.
Но если изучать ядро и качественные плагины, то можно обнаружить 3 базовых подхода к программированию классов.
Классический класс 🙂
Это наиболее частый и понятный метод. Используется метод __construct() для создания экземпляра класса. Но он же наиболее проблемный из-за того что многие программисты могут его не правильно готовить.
Есть 2 способа инициализации:
Анонимный:
new MyPlugin1;
Через присвоение переменной:
$myplugin1 = new MyPlugin;
Назначение
- подходит для задач где требуется наследование
- либо написание каких-то утилит, которые надо запускать в разных местах системы время от времени
Риски и ошибки
Сложный рефакторинг
Класс в котором есть сохранение состояния и много обращений типа $this – далее бывает сложно расцепить, разнести и как то перестроить.
Образуется жесткая сцепка. Очень тяжело отделять части методов и переносить между классами. Растет технический долг, копятся ошибки и т. д.
Цементирование и блокировка хуков
Часто молодые программисты блокируют хуки. Можно случайно зацементировать хуки и заблокировать позднее связывание.
Если класс вызывается через $var = new MyClass; вне глобальной области видимости, то далее все хуки, которые были прицеплены в конструкторе уже никто не сможет отключить. Методы типа remove_action перестают работать с таким классом.
Решение: использовать $GLOBALS или глобальные переменные. Первый вариант рекомендуется.
Но мне лично ни один не нравится.
Избыточные вычисления в конструкторе
Класс дает себя запустить несколько раз подряд. И каждый раз исполняется код в конструкторе. Иногда программисты умудряются туда засунуть сложные механики, которые тратят время. И потом этот класс вызывается по многу раз в разных местах системы. Создавая множество тормозов.
Пример
/**
* The "normal" way. Actions are added in a constructor. Create a new instance
* of the class to "bootstrap" the plugin.
*
* Two ways to instantiate:
* 1. anonymous:
* new MyPlugin1;
* 2. assign it to a variable
* $myplugin1 = new MyPlugin;
*
* The first makes it nearly impossible to unhook things. The second doesn't.
*
* Benefits:
* - Easy to understand and implement
* - Most documentation on using classes in plugins does this
*
* Questionable:
* - Makes it harder to unhook things?
*/
class MyPlugin1
{
public function __construct()
{
add_action('plugins_loaded', array($this, 'loaded'));
}
public function loaded()
{
// do stuff
}
}
Статический класс
Мой выбор. Этот подход использую чаще всего. За его гибкость и возможность переключения в другие стили и подходы. Часто такие механики можно встретить в WooCommerce.
Особенности
- Здорово подходит для инкапсуляции без наследования. Когда нужно сгруппировать методы и данные в рамках решаемой задачи. Но при этом надо запустить 1 раз за запрос.
- Все методы класса статические и публичные.
- Методы относительно легко отцепляются, переносятся между классами, конвертируются в функции, или весь класс относительно легко может быть переработан в обычный
- Вместо __construct() используется метод init()
- Запуск через My_Plugin2::init();
- Плохо подходит для задач с наследование, т.к. унаследование классы могут вести себя непредсказуемо
Пример
class My_Plugin2
{
public static function init()
{
add_action('plugins_loaded', array(__CLASS__, 'loaded'));
}
public static function loaded()
{
// do stuff
}
}
My_Plugin2::init();
Синглтон
Часто применяются там где нужно гарантированно иметь один экземпляр объекта в системе без дублирования.
Плюс более предсказуемая и понятная работа с состоянием объекта чем у Статического подхода.
Быва два типа старта: через init() или instance()
MyPlugin3::init();
MyPlugin3::instnace();
Пример когда нужен 1 Синглтон
class MyPlugin3
{
private static $ins;
public static function init()
{
add_action('plugins_loaded', array(__CLASS__, 'instance'));
}
public static function instance()
{
is_null(self::$ins) && self::$ins = new self;
return self::$ins;
}
private function __construct()
{
add_action('plugins_loaded', array($this, 'loaded'), 20);
}
public function loaded()
{
// do stuff
}
}
Пример образования множества Синглтонов через Абстракцию
/**
* A way to do the singleton pattern with a base class and PHP 5.3+
*
*/
abstract class Singleton
{
/**
* Container for the objects.
*
* @since 0.1
*/
private static $registry = array();
/**
* Get an instance of the current, called class.
*
* @since 0.1
* @access public
* @return object An instance of $cls
*/
public static function instance()
{
$cls = get_called_class();
!isset(self::$registry[$cls]) && self::$registry[$cls] = new $cls;
return self::$registry[$cls];
}
/**
* Init method that adds the `instance` method of the called class to the
* `plugins_loaded` hook.
*
* @since 0.1
* @uses add_action
* @return void
*/
public static function init()
{
add_action('plugins_loaded', array(get_called_class(), 'instance'));
}
/**
* Kill the __clone method.
*
* @since 0.1
*/
private final function __clone()
{
// empty
}
/**
* Subclasses must define construct, this should be where all the other
* actions/filters are added.
*
* @since 0.1
* @access protectect
*/
abstract protected function __construct();
}
class MyPlugin extends Singleton
{
protected function __construct()
{
add_action('init', array($this, 'do_stuff'));
}
public function do_stuff()
{
// do stuff
}
}
Резюме
Все 3 подхода применяются в мире WordPress. К сожалению часто бывает 1-й подход с цементированием событий. Который сильно портит возможности доработки функционала под себя и отключения хуков (remove_action & remove_filter).
Первый подход я применяю только в ситуации программирования утилит, которые нужны время от времени или когда нужно наследование.
Второй подход применяю чаще всего за его гибкость и возможность быстрого рефакторинга при необходимости.
Третий подход – применял один раз для интереса. Но в целом еще не встречал задач где он был бы нужен. Однако в WP через этот механизм работает класс WP_Post и ряд других.
Главное тут понимать что нет единственного правильного подхода. Правильно выбирать подходы адекватные задаче.
Примеры и комментарии к коду взял тут:
https://gist.github.com/chrisguitarguy/3803077
Да, тоже по-возможности использую статические классы.
Вообще вордпресс прикольная админка, популярная. Но в свое время был удивлен, что такого в вордпрессе по-умолчанию нет. Ну точнее внутри в движке классы есть. Но для народа нету. Нету классов для таких вещей как mysql-таблицы, формы, списки элементов и т.д.
А без этого приходится кучу времени тратить на написание всякой рутины, типа очередной код html формы, чтобы добавлять через админку какие-нибудь товары. Тот же вывод этот товаров, просто пишешь постоянно одно и тоже. Уговаривал руководство перейти на какой-нибудь адекватный фреймворк. Но нет. “Вордпресс самая популярная система”. Да, согласен это важно. Но не хочется так разрабатывать, когда рутина рутина…
Как решил этот вопрос?
Теперь пользуюсь специальным плагином https://github.com/mavlutovr/wordpressmvc . Который добавляет в вордпресс mvc. На мой взгляд достаточно мощная вещь. Которая снимает кучу рутинных вопросов. И позволяет быстро разрабатывать не стандартный функционал.
Нужно создать таблицу – создал класс. Описал поля таблицы прямо в массиве внутри этого класса. И все, пользуйся таблицей на здоровье. Даже в phpmyadmin не надо залезать. Тоже самое со списками всяких товаров, других штук. С формами и т.д.
Роман, маппинг класса и таблиц называется ORM. Если он вам нужен, есть куча готовых компонентов для этих целей.
В WP по умолчанию используется иная идеология – EAV (Entity Attribute Value). У нее есть плюсы и минусы в сравнении с ORM. Плюсы – выше гибкость и антихрупкость, улучшается позднее связывание. Минусы – при некоторых условиях можно попасть на тормоза с большими множествами. И надо понимать когда уже пора переходить в SQL. Обычно эта проблема возникает только на больших данных. А даже в крупных системах таких сущностей от 1 до 10%. В 90% случаев EAV выгоднее и эффективнее чем ORM.
По формам. У меня есть опыт разработки сложных и нагруженных систем на WP. С множеством форм. И описанных проблем не наблюдал. Обычно это простые задачи которые решаются 3-4 раза даже если проект очень крупный.
Если у вас так много задач где подобное решение адекватно – наверное оно стоило того.
А может быть это всего лишь очередной экземпляр шизокодинга https://wpcraft.ru/blog/shizokod-i-shizokodery/