Сразу скажу, что с принципами ООП я знакома, ценю и применяю в Delphi, немного в C++. Все преимущества знаю, понимаю. Вопрос не в этом.

Анализируя то, почему я применяю ООП в создании прикладных программ.., мммм... не могу найти смысла в объектном подходе в РНР хотя бы на примере этого самого форума.
Читала где-то, что если не требуется создание более одного объекта некоторого класса, то можно обойтись простым набором функций. Вот пример (из темы http://forum.vingrad.ru/index.php?showtopic=67535):

Код

$this->lib->to_by_id    = $post['author_id'];                         $this->lib->from_member = $this->ipsclass->member;                         $this->lib->msg_title   = '';                         $this->lib->msg_post    = "";                         $this->lib->force_pm    = 1;                          $this->lib->send_pm();

Какие преимущества дает этот класс перед простой функцией?

Код

function send_pm (to_id, subject, body, ...){ . . . }

Я понимаю, что не напрасно люди применяют в программирование на РНР объектный подход. Но смысл пока ускользает...

Помогите просто увидеть преимущества...

Заранее спасибо за внимание

Цитата(Bastet @ 19.11.2005, 16:17)

Какие преимущества дает этот класс перед простой функцией?

В данном случае с данной функцией (если она одна), преимуществ я не вижу никаких..., но:

Цитата(Bastet @ 19.11.2005, 16:17)

Я понимаю, что не напрасно люди применяют в программирование на РНР объектный подход. Но смысл пока ускользает...

если брать в общем, то ООП подход, не важно в какой среде, он помогает создавать более структурированные программы, более читабельные и + экономия символов на коде , но это ИМХО, а также наследование... и т.д.
Это я так думаю...

-=Ustas=-, про все преимущества ООП вообще я знаю (за то и люблю). Мне интересно именно в контексте РНР.

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

Цитата(Bastet @ 19.11.2005, 16:36)

Мне интересно именно в контексте РНР.

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

Цитата(Bastet @ 19.11.2005, 16:36)

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

Опять же скажу - структура, и возможно, меньшее количество переменных..., хотя...ИМХО

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

Или я недопонимаю сути программирования на РНР, или просто туплю...

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

http://vingrad.ru/PHP-ART-002848 - вот тут я в самом начале изложил, так сказать эти вещи.


Bastet не сравнивай ООП в Делфи и ПХП. Сам на Делфи пишу. Это совершенно разные вещи. В Делфи это полноценная теория проектирования и реализации проекта, в ПХП - способ реализации, сама понимаешь, это совершенно разные вещи.

Mal Hack, короче, единственный выигрыш - более структурированный код?
Ясссно....

Цитата(Bastet @ 20.11.2005, 17:28)

Mal Hack, короче, единственный выигрыш - более структурированный код?

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

имеет смысл расмотреть еще и время разработки, доработки, и расширения PHP программы.

Почему же?
Еще можно использовать в качестве единного интерфейса для разных БД например.

Neitron, поподробнее про единый интерфейс к разным БД можно?

Цитата(Bastet @ 30.11.2005, 19:21)

Neitron, поподробнее про единый интерфейс к разным БД можно?

Уровень абстракции от СУБД по просту говря. Хотя в общем не важно СУБД это или нет. Такую абстракцию можно сделать под любого рода сходные источники данных, но реализованные несколько различными интерфейсами. В итоге получится единый интерфейс работы, независимо от используемого источника данных, т.е. приведу примитивный псевдокод:

Код

$db = new db('oracle', 'localhost', 'login', 'pass'); $db->connect(); $db->query('SELECT bla_bla FROM bla_bla_bla'); while ($row = $db->fetch())   echo $row['bla_bla']; $db->disconnect();

Вот благодяря этому единому интерфейсу общения можно аналогичную операцию провести хоть с MySQL, хоть с InterBase хоть еще с чем угодно, при соблюдении стандартов SQL разумеется.
Добавлено @ 19:08

Цитата

...а где наоборот ущемлен (как это является в ПХП).

Про ООП возможности PHP 5 я бы так не сказал...

У меня в проекте 4 типа, ээээ,  я их абстрактно нарек "контентом".
Соответственно у меня 5 классов: абстрактный "контент", и от него наследованы 4 ребенка, для которых общие методы (такие как изменение рейтинга и манипуляция комментами) вынесены в родительский класс. Скажете мелочи? Отнюдь: на добавление/удаление комментов работает один триггер, а не 4. Внешних ключей и таблиц отношений (скажем, у каждого контента есть список жанров, много ко многим, в отдельной таблице) не 4 а одна на все. 
Манипуляции с контентом во многом одинаковы. Что бы ООП начало приносить пользу, нужно научится анализировать и абстрагироваться.
Если нужно манипулировать одним типом контента, то ООП может пригодится в качестве обертки. Простой класс-обертка с понятными именами методов, инкапсулирующих в себе логику. Вот на вскидку уже 2 преимущества.


Лично я убедился в том, что это лишнее. Трудно представить себе проект, который хотят перенести с MySQL на Oracle, например. А соблюдение стандартов SQL надоест очень скоро. В каждой СУБД имеются свои "изюминки", и в рамках стандарта далеко не все получится реализовать. Самый простой пример для этого: попробуйте используя массивы в Postgre перенести скрипты на MySQL.

Bastet, заметь - большинство доводов сводится к "а зато у нас песни хорошие!". Удобство разработки, повторное использование. Это все хорошо, но к сути ООП отношение имеет слабое. Самым убойным из этих аргументов является  применение ООП для эмуляции пространства имен. И такое бывало.
Про суть программ на пхп отлично сформулировано. Линейная, по сути, структура. Плюс время жизни. Можно, конечно, "наструктурировать" себе красивого кода... но, как кто-то метко сравнил в свое время, "была бы виндоус такой, как сейчас, если после каждого клика ей приходилось бы перезагружаться?"
Сюда же - наши реляционные базы. Которые, чтобы отмапить объектно, надо быть очень большим энтузиастом.

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

<Spawn>, а можешь привести не примитивный псевдокод, а реальный пример? Вопрос риторический. 

А вообще, вопрос поднят очень интересный. 
Я дано пытаюсь найти в вебе сущность, которая бы хорошо реализовывалась объектом. Но та же работа базой, которую, с одной стороны, хорошо бы упаковать в класс с кучей свойств и методов, все равно сводится только к одному объекту. И ничем, по сути, не отличается от работы кучи разрозненных функций.
Но я не оставляю надежд найти такую сущность =)

Это сообщение отредактировал(а) Feldmarschall - 19.8.2008, 17:16

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

Собственно для удобства разработчика обектно-ориентированый подход и вводился в свое время. Просто человек устроен сам по себе так что мыслит именно оъектами,ю а не функциями.