ООП стоит использовать в PHP? - PullRequest
18 голосов
/ 23 января 2010

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

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

Ответы [ 9 ]

12 голосов
/ 23 января 2010

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

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

11 голосов
/ 23 января 2010

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

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

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

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

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

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

6 голосов
/ 22 мая 2012

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

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

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

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

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

5 голосов
/ 23 января 2010

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

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

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

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

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

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

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

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

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

С

5 голосов
/ 23 января 2010

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

3 голосов
/ 01 августа 2012

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

Например, если вы разделите свое приложение на модель MVC, ваша Модель может быть ОО, но при этом Контроллер будет упрощенно процедурным.

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

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

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

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

3 голосов
/ 23 января 2010

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

2 голосов
/ 27 июля 2014

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

Вот код теста.

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 голосов
/ 23 января 2010

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

...