При разработке плагина функции должны быть сгруппированы в класс, чтобы избежать конфликтов пространства имен?
Да, но это только один из второстепенных аргументов. Фактически, это не «истинная» природа класса в OOAD .
Создает ли использование классов снижение производительности для PHP?
Нет, не особенно. Плохой дизайн и / или плохо написанный код или преждевременная оптимизация создают гораздо больше проблем с производительностью, чем реальные языковые возможности
Если производительность падает, имена функций должны быть предварительно фиксированными?
Как написано, производительности нет. Плохо написанный код будет скорее ударом по производительности, чем хорошим написанным кодом, который содержит еще несколько строк кода, но не заставляет вас делать плохие вещи.
Нижняя граница:
Вы можете по-разному использовать классы для плагинов. Вы можете просто использовать их, чтобы иметь какое-то пространство имен, и использовать их «просто» для глобальных функций. Наиболее прямой формой этого являются статические функции класса, в следующем примере кода показаны обе: сначала глобальные функции, затем глобальные статические функции класса:
/* global function */
function myplug_hook()
{
}
add_filter('the_hook', 'myplug_hook');
/* global static function */
class myplug
{
public static function hook()
{
}
}
add_filter('the_hook', 'myplug::hook');
Это всего лишь небольшой пример, показывающий, что вам нужно набрать больше для единственного хука. Кроме того, он показывает, как работает пространство имен: Вы можете легко заменить одно имя класса, чтобы переименовать все статические функции, а затем искать и заменять, myplug::что может быть сложнее myplug_из-за ложных срабатываний. Но, в конце концов, нет большой разницы.
Ключевым моментом является то, что статические функции класса Docs не намного больше, чем глобальные функции Docs .
И этот пример также показывает: Пространство имен в порядке, но с worpdress, пространство имен останавливается с использованием хуков: функция обратного вызова жестко закодирована, поэтому преимущество в пространстве имен с использованием класса (одно место для base-name, classname) не помочь, когда вы вводите свой код с WordPress для имен хуков.
Реальное преимущество начинается с использования реальных экземпляров классов и нестатических функций. Это дает то преимущество, что вы можете начать использовать принципы ОО и оптимизировать свой код. Статические функции класса являются скорее проблемой, чем решением проблемы.
Тогда это больше, чем просто синтаксический сахар.
Ключевой момент: сделайте то, что поможет вам написать код, с которым вы легко сможете справиться и поддерживать. Не переоценивайте производительность, это распространенная ошибка. Более важно то, что вы пишете код, который легко читать и понимать, который просто делает то, что вам нужно. Может быть, этот вопрос и ответ полезны для большей картины в этом контексте: Справка по нескольким настраиваемым Metabox .
Один общий подход, который я использую даже с небольшими плагинами, заключается в использовании статической вспомогательной функции для создания экземпляра плагина, а остальное находится в экземпляре плагина. Это помогает инкапсулировать основную логику плагина и дает преимущество от пространства имен с перехватчиками, а также позволяет повторно использовать закрытые члены между перехватчиками, что невозможно в стандартных глобальных функциях. В следующем примере кода показан шаблон:
<?php
/** Plugin Headers ... */
return MyPlugin::bootstrap();
class MyPlugin
{
/** @var MyPlugin */
static $instance;
static public function bootstrap() {
if (NULL === self::$instance) {
self::$instance = new __CLASS__;
}
return self::$instance;
}
# ...
}
Это общий шаблон, который я использую для базового файла плагина. Класс плагина, с одной стороны, представляет собой плагин для WordPress, а с другой стороны, он позволяет начать использовать объектно-ориентированные парадигмы для собственного кода, который может быть даже полностью объектно-ориентированным (но не обязательным). Это своего рода контроллер, взаимодействующий со всем API WordPress как запрос (ы).
Как показывает пример, будет создан экземпляр плагина. Это позволяет вам использовать известные общие ресурсы, такие как Constructor Docs ( __construct), для инициализации реального плагина:
# ...
class MyPlugin
{
# ...
public function __construct()
{
add_filter('the_hook', array($this, 'hook'));
}
public function hook()
{
}
# ...
}
В то время, когда ловушка зарегистрирована, этот объект плагина уже получает выгоду от своего дизайна: вы перестали жестко кодировать реальную функцию ловушки против конкретного имени класса плагина . Это возможно из-за привязки класса к экземпляру объекта для обратного вызова. Звучит сложно, просто сказать: $this это плагин. Может использоваться в обратных вызовах хуков, сравните методы регистрации класса как обратные вызовы хуков .
Этот шаблон позволяет упростить взаимодействие с WordPress: инъекция сводится к именам хуков и тем, какие данные они предоставляют. Затем вы можете начать внедрять непосредственно в этот класс плагинов или реорганизовать свою реализацию против него, чтобы поместить код только в класс плагинов, который является минимальным для определения интерфейса ваших плагинов для WordPress, но оставьте общую логику в стороне от worpdress. Именно здесь начинается самое интересное, и, скорее всего, этого хочет добиться каждый автор плагина в долгосрочной перспективе.
Так что не программируйте с worpdress, а против него. Поскольку worpdress достаточно гибок, нет общего или простого описания интерфейса для программирования. Базовый класс плагинов может взять на себя эту роль, предоставляя вам большую гибкость для вашего собственного кода, что приведет к упрощению кода и повышению производительности.
Таким образом, есть больше, чем просто преимущество для имен. Лучшее предложение, которое я могу дать: попробуй сам. Не так много вы потеряете, только новые вещи, чтобы открыть.
Скорее всего, вы заметите различия после того, как пройдете более важные обновления WordPress, сохраняя совместимость вашего плагина.
Предостережение : если ваш плагин напрямую интегрируется с WordPress для выполнения работы, использование одной или двух открытых функций может вам подойти. Возьмите правильный инструмент для работы.