Расширение класса PHP против передачи объектов в качестве параметра - проблема производительности

Question

Мне нужно создать класс для создания (и отправки, проверки и т. Д.) Веб-форм. У меня также есть класс для генерации необработанного HTML путем написания кода PHP.

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

1. Составление формы класса расширение класса HTMl: class WebForm extends HTML {}

2. Я уже создал объект класса HTML (пусть, $html) для некоторых других целей в моем проекте. Я могу передать это как параметр в конструкторе класса WebForm:

   class WebForm{
   
       public $html;
   
       public function __construct($html) {
           $this->html = $html;
       }
   }
   
   $html = new HTML(); //  already created for some other purpose
   $webform = new WebForm($html);
   

Какой метод будет быстрее и почему?

Answer 1

Честно говоря, вы никогда не сможете получить грамотный ответ, пока не напишите свое приложение (или прототип) и не начнете профилировать, в противном случае вы получите ответы, основанные на предположениях.

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

Я предлагаю вам реализовать оба подхода и убедиться в этом самим. Существуют инструменты для помощи в профилировании (например, xdebug).

Answer 2

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

Лучше всего использовать метод составления .

Кстати, вам следует серьезно подуматьперемещение всего вашего HTML-генерирующего кода в шаблонизатор.Просто визуализируйте шаблоны из своего класса формы и выполняйте только валидацию в PHP, а не генерацию HTML, иначе вы в конечном итоге будете выполнять связанные с представлением задачи в своих контроллерах.

Answer 3

Если говорить в терминах C, подход наследования будет быстрее на одну операцию разыменования указателя, чем подход агрегации (который требует дополнительного разыменования $this->html). В PHP это должно быть сопоставимо.

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

Наконец, рассмотрите возможность использования в классе Html только методов static. Это вполне разумно, так как это вспомогательный класс, поэтому ему не нужно поддерживать какое-либо состояние. Если по какой-то причине вы чувствуете, что ему нужно какое-то состояние, попросите вызывающих абонентов сохранить его и передать его Html в качестве параметров функции. Это не только улучшит ваш дизайн, но также удалит дополнительное разыменование указателя, о котором мы говорили выше. И в качестве дополнительного бонуса, он полностью сведет на нет затраты на создание экземпляров Html, даже если вам нужно создавать экземпляры нескольких объектов WebForm в течение времени жизни одного запроса (оба варианта, которые вы считаете подходящими, имеют этот недостаток).

Answer 4

Это почти наверняка имеет незначительное значение, если только вы не делаете миллионы вызовов HTML методов.

Если бы мне пришлось угадывать (а это действительно только предположение), то я бы сказал, чтоВариант № 1 может быть быстрее (и пренебрежимо мало).Смысл в том, что для вызова HTML методов требуется еще один уровень косвенности.Но единственный способ подтвердить эту теорию - это профилировать каждую опцию по очереди.

Обратите также внимание, что сначала вы должны разрабатывать свои классы для ясности, во-вторых, для производительности (и только после того, как подтвердите, что это проблема).Например, вы должны спросить себя, имеет ли смысл иметь WebForm extension HTML;имеет ли смысл говорить, что Webform является HTML?