Ну как же, во всех RAD MVC фреймворках: клонах и не клонах RoR.

С фреймворками не работал, к сожалению, либо очень мало и не на PHP...

Daevaorn, кстати, меня всё интересует... все хвалят ORM... как я понял, то с его помощью можно и загружать данные из базы в объект. Если я правильно понял, то вопрос: Откуда гарантия что запрос к БД будет оптимальным с точки зрения производительности?

такой гарантии нет. все зависит от авторов ORM библиотеки. благо их щас развелось достаточно много и есть из чего выбрать. но всё равно в нетривиальной ситуации оптимальный запрос напишет только сам человек. поэтому иногда приходится ручками до SQL снисходить. обычно для этого тоже предусмотрены специальные инструменты, которые позволяют даже на основе "ручных" запросов создавать в итоге объекты. Зато ORM очень выручает, когда сложных запросов не много и нужно просто получить список неких объектов без сложных условий. ну и бесплатно получается некая структурность кода

Согласен, забивать ни на что нельзя. Все потом боками вылезает.


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

Mal Hack, 
Я выше дал ссылку на propel. Наверное зря... штука пугающая. Лучше ORM посмотреть на ezpdo. Там всё проще и без заморочек...

Вот я про это отличие и говорю.

SamDark, посмотрю на досуге.

Автомат тоже кто-то делал ручками. Что нам мешает один раз сделать и наслаждаться?

Ничего не мешает. Я с этим и не спорю, а наоборот придерживаюсь этого мнения.

"Чтобы понять рекурсию, надо понять рекурсию" ))

chief39, 
+1

Если писать CMS или что-то, что в дальнейшем будет очень часто модифицироваться, то естественно ООП. Если же нам нужно получить небольшой скрипт, который будет работать на большинстве платформ, причем быстро - тогда процедурное.

Прочитал данную тему пока только до середины, и внесу свои 5 копеек.

Я программирую на php. Нигде не учился, все сам. И так, что мы имеем.

Что такое класс? Нет это не class myClass {} а это КЛАСС каких либо повторяющихся вещей, предметов и т.д. 
Теперь что такое объект этого класса? Нет это не $Object = new myClass; А это один экземпляр класса. 

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

Теперь для того чтобы создать сколько угодно кнопок, достаточно создать объект кнопки примерно так:

$button = new myButton;          // class myButton extends basicButton {
$button->name = 'Моя кнопка';  // Текст на кнопке

$window = new myWindow;
$window->setButton($button);

Все, кнопка отобразилась на окне, красота? Я думаю да. Понятно все? Да. ООП мне нравиться? Да.


Ок. Разберем еще один пример, играем мы в стратегию, и там есть юниты, все они похожи, но кое в чем разнятся, ёмаё, да это еще один класс и его расширение.

И таких примеров много!!! Но теперь вернемся к нашему php, я пока для себя нашел только один похожий на примеры выше код.

Чуть предисловия:
Класс базы данных. Раньше я делал так, создавал объект базы данных, в котором были методы конекта, отправки запроса, проверки данных, получения результата и т.д. На одном из форумов, или у кого то в библиотеки я подсмотрел идею что класс mysql должен только конектится, и делать запросы, а вот результат отдается в виде объекта, с которым я могу работать. Более того, при работе с результатом есть много общих действий для всего класса ответов на запросы, например освобождение памяти, получение размера, и т.д. Здесь ооп мне понравилось. Я понял его суть. 

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

К сожалению других применений ООП в php я пока не вижу. 

В общем вот что я думаю.

Добавлено через 4 минуты и 20 секунд

Позволю себе не согласиться, например все та же злосчастная кнопка является объектом!!! С ней удобно работать как с объектом. 

отличить ООП-код от не-ООП на самом деле очень просто:
1. Берем исходники
2. Ищем полиморфизм
...
PROFIT
т.е. фактически сама задача определяет, будет ли использовано ООП. Нету юнитов - нету меда ;)

по поводу событийности/визуальности... разделение, естественно, имеет место быть. Хорошо, а что важнее событийность или визуальность? Возьмем, например, java/c# в контексте веба. В php событийность - это запросы от сервера, только все объекты умирают от запроса к запросу. В java/c# это не так (насколько я знаю). Т.е. вроде как событийность есть, но нету визуальности...

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

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

ООП - это гламурно