2010-01-23 6 views
17

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

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

+20

- микросекунды для обработки клеток мозга? откройте источник чего-то вроде CakePHP или CodeIgniter, затем сравните с источником wordpress, а затем скажите, что последнее не поощряет вас разбивать лицо на клавиатуру. – seanmonstar

+5

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

+0

@seanmonstar: Вы имеете в виду Wordpress не OO ?! ** o_O '** –

ответ

10

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

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

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

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

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

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

+0

Всегда использовать глобальные функции - это плохая идея, потому что она занимает много места. Но, было бы хорошо использовать $ GLOBALS ['class']? Это может быть длиннее, но было бы полезно использовать, если бы вы использовали только один класс. – ambiguousmouse

+3

'$ GLOBALS' - это в основном то же самое. Вы создаете глобальную переменную. –

+0

Так что я могу просто использовать $ GLOBALS ['class']. Затем на другой строке просто используйте $ class? – ambiguousmouse

12

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

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

2

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

+0

Huh. почему использование OOP не подразумевает копирование + вставное кодирование? –

+0

процедурное программирование не может использоваться повторно. хотя вы можете сделать эту ошибку и в ООП :) – Chris

+0

Почему бы не использовать повторно? Вы можете написать очень, очень общий, процедурный код. См. Стандартную библиотеку C++ (например, 'std :: sort'), см. Стандартную библиотеку C (наиболее заметно« qsort »). Процедурный код, не подлежащий повторному использованию, полностью подразумевает, что вы можете использовать каждую функцию один раз и один раз, что, конечно, немного не очень хорошо. –

5

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

5

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

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

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

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

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

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

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

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

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

C.

5

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

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

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

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

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

3

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

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

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

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

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

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

2

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

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

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