Форум PHP

Давайте обсудим такую проблему. Действительно ли ООП снижает производительность. Да, снижает, но намного ли? Все зависит от реализации класса.
Давайте проведем опыт. Сделаем элементарную вещь, как обычным путем, так и с помощью классов. Мы не будем использовать дополнительные ресурсы, такие как базы данных, файлы, сокеты и т.д. Создадим классы, ну как в примере каком-либо.

<? class Test {     private $id;     private $name;     private $msg;          public function __construct($id, $name, $msg)     {         $this->id = $id;         $this->name = $name;         $this->msg = $msg;     }          public function getId()     {         return $this->id;     }     public function getName()     {         return $this->name;     }     public function getMsg()     {         return $this->msg;     } } class Tester {     public function Select()     {         $array = array();         for($i=0; $i<1000; $i++)         {             $id = $i;             $name = 'name_'.$id;             $msg = 'msg_'.$id;             $array[] = new Test($id, $name, $msg);         }         return $array;     } } $time_start = microtime(1); $tt = new Tester(); $ar = $tt->Select(); foreach($ar as $r) {     echo $r->getId().' == '.$r->getName().' == '.$r->getMsg().'<br />'; } $time_end = microtime(1); $time = $time_end - $time_start; echo $time; ?>

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

Теперь сделаем все это более обычным способом:

<? $time_start2 = microtime(1); for($i=0; $i<1000; $i++) {     echo $i.' - name_'.$i.' - msg_'.$i.'<br />'; } $time_end2 = microtime(1); $time2 = $time_end2 - $time_start2; echo $time2; ?>

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

У меня в первом случае появилась такая цифра - 0.11839699745178
Во втором - 0.076011180877686

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

Мне кажется что вы не то сравниваете. Надо сравнивать трудозатраты на сопровождение продукта. Ясно что класс и места займет больше и памяти и писать его дольше... но ведь не для удовольствия это делают... Хотя, в php скорее для удовольствия - объективных причин для этого нет.

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

>Трудозатраты - это дело тонкое.
Именно об это я и говорю. Если бы можно было получить однозначный ответ серией тестов, то уже давно всем бы было известно что "В php не надо использовать объектный код, потому что..." или наоборот "надо использовать только ООП, по следующим причинам...".
Ваш же тест доказывает лишь то, что в php задачу можно решать как с помощью ООП, так и без него.
То есть полезной информации - ноль.

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

Классы начинают себя оправдывать при наследовании прежде всего. Страшно представить программу с виндосовскими окнами без ООП. В С++ есть еще прекрасный механихм позднего связывания. Не слишком быстрый, но до жути удобный, если его правильно использовать. Не знаю, есть ли он в ПХП.

Нет, в РНР многого нет, а хотелось бы, но возникает вопрос а зачем? Нет же строгой типизации, нет же перегрузки функций. Кстати, представьте себе, что страница - окно, а сайт - набор окон, а каждое окно имеет свои элементы - формы и другие html объекты. Вот и получится ASP.NET :)

Не нравится - не используй. Только других своими выводами не деградируй.

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

А зачем в журналах страницы? Продавали бы рулон. Постраничную навигацию придумали прежде всего чтобы пользователю было удобно с таким списком работать

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

При чем здесь понятен не понятен? Если не понятен - учи ООП.

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

И для такого тоже, но нагрузка все-таки снижается.

Если не понятен - учи ООП

Я как раз про это и говорил.

Пост не про то понятен ООП или нет, пост про производительность. Мне бы хотелось прочитать мысли форумчан по этой теме.

Любой язык - не просто инструмент программирования, но это и самый натуральный диалект, на котором мы общаемся с компом. А чем более высоко организован диалект, тем более развит его носитель. Каждый язык некоторым образом уже имеет в себе предпосылки решения задачи. Я заметил, что на Паскале мои программы получаются более формализованными, а на С - более гибкими. Задачи, с легкостью решаемые на Лиспе или Прологе порой бывает почти невозможно адекватно представить в процедурах, но это уже крайность. Суть-то в чем: ООП, как образ мысли, поднимает программиста на более высокий уровень по сравнению с процедурником. Вот и думайте...

Я знаю ООП как на РНР, так и на Си Шарп и Джава. То, что в РНР ОО модель содрана со Джава я умолчу. Образ мысли... ну да. Есть такое. Но я еще раз повторюсь, что тема не про образ мысли, уровень программиста, а про произвоительность.

> Но я еще раз повторюсь, что тема не про образ мысли, уровень программиста, а про произвоительность.

А я повторюсь, что здесь ответ не может быть однозначным. Конечно, когда у меня есть некая фуекция с аргументами, а я измудряюсь оформить ее классом, то, может быть, производительность и будет потеряна (как, собственно, и в примере). ВЫИГРЫШ в производительности появляется тогда, когда средствами ООП мы предлагаем более оптимальное решение, чем в случае с процедурным подходом.

Тот код, что представлен здесь лишь пример, очень легкий. Вот и все.

>Суть-то в чем: ООП, как образ мысли, поднимает программиста на более высокий уровень по
>сравнению с процедурником.
Поправочка - ООП никуда никого не поднимает - программист поднимается на новый абстрактный уровень сам, причём может делать это без ООП инструментов. Более того, многие ООП-разработчики как раз и не поднимаются на новый абстрактный уровень, а используют классы как контейнеры из которых потом последовательно вызываются методы - т.е. продолжают работать в процедурном стиле.

используют классы как контейнеры из которых потом последовательно вызываются методы - т.е. продолжают работать в процедурном стиле.

Типо тупо функции?

Да, но в данном случае классы служат неким подобием пространству имен.