Все плагины должны инкапсулироваться в Классе?

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

Использование классов создает издержки производительности для PHP?

Если существует хит производительности, имена функций должны просто быть снабжены префиксом вместо этого?

29
18.08.2011, 00:38
5 ответов

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

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

Ключевой пункт: статические Документы функций класса действительно очень еще не являются затем глобальным functionsDocs.

И этот пример показывает также: Пространство имен прекрасно, но с worpdress, остановками пространства имен с использованием рычагов: функция обратного вызова является hardencoded, следовательно преимущество в пространстве имен с помощью класса (одно место для базового имени, имени класса) не помогает, когда Вы вмешиваетесь в действия свой код 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, и с другой стороны он позволяет начинать использовать объектно-ориентированные парадигмы для собственного кода, который может даже быть абсолютно объектно-ориентирован (но не должен быть). Это - своего рода контроллер, взаимодействующий через интерфейс с целым Wordpress API как запрос (запросы).

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

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

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

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

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

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

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

Вы по всей вероятности заметите различия после передачи еще некоторых основных обновлений Wordpress при сохранении плагина совместимым.

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

24
19.02.2020, 21:55
  • 1
    Если статические функции класса действительно не отличаются от глобальных функций, и Ваша цель состоит в том, чтобы предотвратить конфликты пространства имен, я действительно не понял необходимости (все же) для переключений на запись плагинов как классы. Кроме того, я смущен Вашей функцией начальной загрузки помощника. Почему не только объявляют новый объект как $new_object = новый MyClass ();? –  AlxVallejo 30.12.2012, 19:10
  • 2
    @AlxVallejo: Для одного только пространства имен нет никакой истинной необходимости (как я записал в ответе, статические методы класса являются в значительной степени тем же как глобальными функциями). Таким образом, можно сделать пространство имен собственное (пред вид PHP 5.3 пространства имен, которое является). Таким образом, Вы заметили что совершенно правильный. Похожий со статической функцией начальной загрузки: Технически это не необходимо, простое return $myPlugin = new MyPlugin(); он также. Однако для большего изображения, простое новое могло бы быть недостаточно, сравнить Плагин WordPress: Как я избегаю “плотного соединения”?. –  hakre 18.01.2013, 15:58

Классы набор функции VS


Производительность

Общая информация: Afaik, нет никакого различия в "производительности" между классами и функциональными наборами.

Деталь:

  • Существует большая разница, если Вы подвергаете сомнению function_exists() по сравнению с. class_exists() поскольку обычно Вы получили много функций (~1.800(?) в wp ядре) по сравнению с классами (~100(?) в wp ядре). Так создание "сменного" материала и поэтому опрос существования являются различием во время выполнения.
  • Классы предлагают одно большое преимущество перед функциональными наборами: Вы можете намного легче стараться не называть его по запросу, где Вам не нужен он, затем с функциями. Только необходимо сделать условные проверки на класс а не на каждую функцию. Таким образом, если Вы не нуждаетесь в нем на каждой загрузке страницы и можете постараться не звонить, многие из если/еще операторы, функция "работает лучше".

Архитектура - Как материал работает:

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

Класс: существуют различные подходы к классам. Класс, который прибывает самый близкий к функциональному набору, является классом "фабрики" (Википедия/Google). Imo это - почти то же как ряд функций, но инкапсулировавший в классе. Но существуют другие "типы" классов также. Вы могли, например, записать краткий обзор или класс родительского класса, который Вы расширяете с помощью дочернего класса. В примере реального мира: Скажем, Вы получили класс, который создает некоторые поля статического текста. В Вашем __construct() функция у Вас есть ряд сценариев как "left_column", "right_column" и "footer_field". Затем Вы называете что-то как $text_field = new TextFieldClass(); инстанцировать класса. И позже Вы просто звоните $text_field->add( $case => 'left_column', 'case' => 'foo text' ); и $text_field->add( $case => 'footer_field', 'case' => 'bar text' );. Затем все Ваши условные выражения и еще были уже выполнены, когда Вы инстанцировали класса, и просто две функции класса будут вызваны при создании текстовых полей. В этом szenario Вы, возможно, сохранили некоторый мс времени выполнения.


Личное мнение

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

Пример:

// construction of object
if ( ! class_exists( 'WPSE_HelloWorld' ) )
{

class WPSE_HelloWorld
{
    function __construct( $args = array( 'text', 'html', 'echo' ) )
    {
        // call your object building procedures here
        $this->hello_world( 'text', 'html', 'echo' );
    }

    function hello_world( 'text', 'html', 'echo' )
    {
        $start_el = '<{$html}>';
        $end_el = '</{$html}>';
        if ( $echo )
        {
            return print "{$start_el}{$some}{$end_el}";
        }

        return "{$start_el}{$some}{$end_el}";
    }
} // END Class 

}

// API: public functions
function the_hello_world( $args( 'echo' => true ) )
{
    $new = new WPSE_HelloWorld();
    return $new->hello_world( $args );
}

function get_hello_world( array( $args( 'echo' => false) ) )
{
    $new = new WPSE_HelloWorld();
    return $new->hello_world( $args );
}

// then you can call it like get_the_title() or the_title(), which you know from the WP API:
// 'echo' is set to false per default:
$some_var = get_hello_world( array( 'text' => 'hello reader', 'html' => 'strong' ) );
# *returns* "<strong>hello reader</strong>"

// 'echo' is set to true per default:
the_hello_world( array( 'text' => 'hello reader', 'html' => 'strong' ) );
# *prints/echos* "<strong>hello reader</strong>"

Примечание: Также прочитайте ссылку @t310s отправленный в комментарии на Q.

9
19.02.2020, 21:55
  • 1
    , просто любопытный, почему Вы ожидаете, что Ваш сменный файл будет включен несколько раз с Wordpress? –  hakre 18.08.2011, 03:34
  • 2
    @hakre, Где точно я говорил это? sry, довольно усталый в маме. –  kaiser 18.08.2011, 04:36
  • 3
    @kaiser, я предполагаю, что @hakre относится к if( ! class_exists ) строка Вы имеете вначале? –  jjeaton 18.08.2011, 08:32
  • 4
    @hakre, я принимаю @kaiser, делает class_exists проверьте, не потому что это могло быть включено больше затем однажды, но избегать конфликта с другим классом? –  Michal Mau 18.08.2011, 19:35
  • 5
    Да я задавался вопросом о class_exists. –  hakre 18.08.2011, 22:05

Это - чисто стилистический выбор со стороны сменного автора. Нет никакой реальной разницы с точки зрения скорости.

4
19.02.2020, 21:55

Классы обычно не предлагают преимуществ с точки зрения производительности, но они очень редко имеют любые отрицательные эффекты также. Их реальная выгода находится в создании более четкого кода и предотвращение конфликтов пространства имен.

1
19.02.2020, 21:55
  • 1
    Все же, как @hakre упомянутый, пространство имен конфликтует, действительно не отличается при использовании префиксов на глобальных функциях. "Более чистый" код и предотвращение конфликтов пространства имен синонимичны в этом случае, нет? –  AlxVallejo 30.12.2012, 19:18
  • 2
    @AlxVallejo i думаю так :) –  Bainternet 30.12.2012, 21:01

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

С классами у Вас просто было бы название плагина в имени класса, вероятно, однажды.

Кроме того, можно использовать наследование или другие конструкции oo для реализации поведений очень чистым способом. Вот исключая:

class animalplugin{
  //plugin functions...
  function talk(){print "animalnoise";}
}
class animalplugin_with_cat_mods extends abcplugin{
  //cat functions overrides
  function talk(){print "meow";}
}
if (iscat()){
  new animalplugin_with_cat_mods();
} else {
  new animalplugin();
}
0
19.02.2020, 21:55