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

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

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

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

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

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

C.

Answer 6

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

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

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

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

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

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

Answer 7

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

Вот эталонный код.

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

Answer 8

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

Answer 9

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