Стоит ли использовать ООП в PHP?

существует много споров о том, является ли объектно-ориентированное программирование хорошим или нет. Но использование ООП в Php медленнее. Было бы хорошей торговлей использовать процедурное программирование и более быструю скорость и ООП с более медленной скоростью (поскольку классы должны инициироваться каждый раз, когда загружается страница, и большие веб-сайты начнут замедляться).

Что еще более важно, было бы хорошо обернуть материал внутри класса и использовать статические функции или было бы лучше просто иметь много лежащих функций с префикс ex: wp_function().

18
oop performance php procedural

9 ответов

да, почти всегда хорошая идея использовать ООП. Это связано с тем, что ООП-это стиль кодирования, а стили кодирования по большей части легко переносятся через языки.

люди не используют стили кодирования, потому что они используют определенный язык. Люди используют стили кодирования, потому что стиль кодирования предлагает хорошие методы, чтобы делать то, что они считают желательным. Поэтому, пока существуют базовые элементы (наследование, свойства класса и т. д.), Он всегда будет можно писать в таком стиле.

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

function myFunc()
{
    global $class;
    $class->doMethod();
}

function myFunc2()
{
    global $class;
    $class->doMethod2();
}

это плохая идея, поскольку она создает тонну глобального состояния.

11

Если причина, по которой вы беспокоитесь об использовании OO с PHP, - это скорость, не бойтесь: PHP-это медленный язык. Если вы делаете что-то достаточно интенсивное для потери скорости от использования объектов, вы вообще не должны использовать PHP.

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

12

те же аргументы о производительности были сделаны о Objective C и C++ в день. И ответ на эту проблему состоял в том, чтобы воспользоваться доступной памятью и вычислительной мощностью, которая постоянно становится больше, лучше и быстрее.

да, OO требует больше ресурсов для запуска. Но преимущества использования OO перевешивают аппаратную стоимость $ $ (которая, вероятно, будет незначительной) поддержки приложений OO.

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

имейте в виду, что, хотя PHP не может быть самой быстрой платформой (Java, например, пинает ее прикладом), PHP используется для питания некоторых из самых тяжелых веб-сайтов в Интернете: а именно Facebook.

Если у вас есть какие-либо другие сомнения в PHP и OO, просто посмотрите на Zend и Magento (на основе Zend). Magento является очень ресурсоемкая платформа, использование памяти может быть выше 36 Мб на экземпляр. Однако сама платформа способна обрабатывать миллионы просмотров. Это связано с тем, что правильно настроенная серверная среда со здоровой подачей аппаратных ресурсов делает все преимущества использования OO намного превосходящими стоимость самого сервера. Но в мире кластерных компьютеров, не использующих обработку сила и память (ответственно) доступны вам-ИМХО-клиническое безумие.

6

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

5

Я категорически не согласен с ответом Chacha102.

правильный ответ на этот вопрос заполнит несколько книг-не говоря уже о 20-строчном сообщении здесь.

оба подхода имеют свои преимущества и недостатки. Я бы рекомендовал всем, кто хочет считать себя хорошим программистом, иметь значительный опыт в процедурном, не процедурном и объектно-ориентированном программировании. А также опыт работы с различными методологиями, такими как SCRUM, cascade и РАДИАН.

Что касается пригодности PHPs для OO против процедурного кодирования, конечно, корни языка находятся в последнем (но обратите внимание, что Java и ASP являются гибридными, а не истинными языками OO).

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

утверждать, что вы всегда должны писать процедурный код, потому что он будет работать быстрее, чем код ОО:

1) не обязательно верно 2) полностью игнорирует относительную стоимость времени разработчика против аппаратных затрат

было бы хорошо обернуть материал внутри класса и использовать статические функции

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

С.

5

ООП имеет больше достоинств, чем его заслуги. см. PHP OOP, каковы преимущества?. Также смотрите для ООП против PP в PHP.

3

на самом деле нет идеального ответа, поскольку он зависит от стольких неизвестных переменных, и тогда он не должен быть "все или ничего".

например, если вы разделите свое приложение на модель MVC, у вас может быть модель OO, но держите контроллер более упрощенно процедурным.

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

Если вы строите небольшая одностраничная веб-форма, которая снимает сообщение по электронной почте, вам действительно не нужен OO-чтобы вы, возможно, включили существующий почтовый класс для использования.

никто не может дать вам правильный совет, не понимая проект, который вы берете на себя.

Что сказал, Если ваша единственная забота скорость, то ОО будет быть немного медленнее. И есть много подлых вещей, которые вы можете сделать даже в процедурном PHP, чтобы имитировать некоторые из выигрышей OO. Но если вы не принимаете на себя огромный проект, дополнительное время никогда не будет много. И к тому времени, когда у вас будет огромный проект, плюсы OO могут перевесить минусы его накладных расходов.

3

да по мере роста вашего приложения.. (и это будет) это избавит вас от многих часов разочарования. И повторяя себя (копируя код вставки повсюду).. :)

2

мне было любопытно об этом сам. К сожалению, после того, как я изменил свой код с процедурного на ООП, я запустил некоторые тесты, а не заранее.

вот контрольный код.

class game{
  function maxp($val){
    return max(0,pow($val,0.5));        
  }
}

$game = new game;

for($i=0;$i<100000;$i++){
  $game->maxp(100);
  //game::maxp(100);
}

результаты ООП колебались между 0,13 и 0,2 секунды;

процедурные результаты колебались между 0.08 и 0.1 секундами.

результат оставался неизменным в течение длительного времени.

Я призываю вас, чтобы построить свои собственные тесты.

в PHP 5.4.3

2