Должны ли все плагины быть инкапсулированы в класс?

При разработке плагина следует ли группировать функции в класс, чтобы избежать конфликтов пространств имен?

Да, но это только один из второстепенных аргументов. На самом деле это не "истинная" природа класса в 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_ из-за ложные срабатывания. Но в конце концов особой разницы нет.

Ключевым моментом является: статические функции класса ^{Документы} на самом деле это не что иное, как глобальные функции ^{Документы}.

И этот пример также показывает: Пространство имен в порядке, но в worpdress пространство имен останавливается с использованием крючков: функция обратного вызова жестко закодирована, следовательно, преимущество в пространстве имен с использованием класса (одно место для базового имени, имя класса) не помогает, когда вы вводите свой код в wordpress для имен крючков.

Реальная выгода начинается с использования реальных экземпляров классов и нестатических функций. Это имеет то преимущество, что вы можете начать использовать принципы OO и оптимизировать свой код. Статические функции класса - это скорее проблема, чем решение.

Тогда это больше, чем просто синтаксический сахар.

Ключевой момент: Сделайте что-нибудь, что поможет вам написать код, который вы можете легко разбираться и поддерживать. Не переоценивайте производительность, это распространенная ошибка. Более важно, чтобы вы писали код, который легко читается и понимается, который просто делает то, что вам нужно. Возможно, этот вопрос и ответ полезны для более широкой картины в этом контексте: Справка по нескольким Пользовательским Метабоксам.

Один из распространенных подходов, который я использую даже с небольшими плагинами, заключается в использовании статической вспомогательной функции для создания экземпляра плагина, а остальное находится в экземпляре плагина тогда. Это помогает инкапсулировать основную логику плагина и извлекает выгоду из пространства имен с помощью крючков, а также из того, что частные члены могут быть повторно использованы между крючками, что невозможно при использовании стандартных глобальных функций. Следующий пример кода показывает шаблон:

<?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 в качестве запроса(запросов).

Как показано в примере, будет создан экземпляр плагина. Это позволяет вам использовать известные общие ресурсы, такие как конструктор ^{Документы} (__construct) чтобы инициализировать фактический плагин:

# ...
class MyPlugin
{
    # ...
    public function __construct()
    {
        add_filter('the_hook', array($this, 'hook'));
    }

    public function hook()
    {
    }
    # ...
}

На момент регистрации крючка этот объект плагина уже выигрывает от своего дизайна: вы прекратили чтобы жестко запрограммировать фактическую функцию привязки к конкретному плагину имя класса . Это возможно из-за привязки класса к экземпляру объекта для обратного вызова. Звучит сложно, просто говорю: $this является плагином. Может использоваться в обратных вызовах, сравните Регистрация методов класса в качестве обратных вызовов.

Этот шаблон позволяет упростить интерфейс с wordpress: ввод сводится к именам крючков и данным, которые они обеспечивать. Затем вы можете приступить к реализации непосредственно в этом классе плагинов или к рефакторингу своей реализации по отношению к нему, чтобы поместить код только в класс плагинов, который является минимальным для определения интерфейса ваших плагинов в wordpress, но оставьте общую логику в стороне от worpdress. Здесь начинается самое интересное, и, скорее всего, это то, чего каждый автор плагина хочет достичь в долгосрочной перспективе.

Так что программируйте не с помощью worpdress, а против него. Поскольку worpdress довольно гибкий, существует нет общего или простого в описании интерфейса для программирования. Базовый класс плагинов может взять на себя эту роль, предоставляя вам больше гибкости для вашего собственного кода, что приведет к упрощению кода и повышению производительности.

Таким образом, есть нечто большее, чем просто преимущество для интервалов между именами. Лучшее предложение, которое я могу дать, это: Попробуйте сами. Вы мало что потеряете, только новые вещи, которые нужно открыть.

Вы, скорее всего, заметите различия после того, как пройдете еще несколько крупных обновлений wordpress, в то время как поддержание совместимости вашего плагина.

Предостережение: Если ваш плагин напрямую интегрируется с wordpress для выполнения работы, использование одной или двух общедоступных функций может подойти вам лучше. Возьмите подходящий инструмент для этой работы.