Целесообразность ООП в php и веб-сервисах

Здравствуйте!

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

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

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

Конкретный пример:
Система продукт - ингридиенты продукта.
Надо получить состав продукта, наименование его ингредиентов, цену, ед изм, и другую информацию о них.
Продукт - объект, ингредиенты - объекты. Хорошо, в объекте "Продукт" вызываю функцию "Получить состав". Функция берет из базы ID составляющих продукт ингредиентов и на основе них, по классике ООП, создает массив объектов "ингредиентов" и возвращает его. Получается, на каждый ингреидиент создается свой объект (расход памяти), каждый объект обращается к БД, у него свои прибамбасы (проверка на существования ID в конструкторе и другое), то есть для такой вроде бы элементарной операции создаются кучи запросов к БД и используется много памяти.
Хорошо, с другой стороны можно не создавать массив объектов в функции, а просто выдернуть из базы информацию об этих ингредиентов разом и возвратить их в виде массива. Но в таком случае мы уходим от концепции ООП (дублируется код (получение информации об ингредиенте происходит и в самом классе ингредиента, и в классе продукта), уходим от абстракции и прочее.
Или еще пример:
В каком-то участке программы нужна специфическая информация о продукте, или группы продуктов, пихать всевозможные варианты в объект, делать его универсальным (в тоже время громоздким)? или из того места напрямую обратиться к БД и получить нужную информацию?
С одной стороны, мне симпатизирует ООП, его логичность и организованность, абстрагированность. Но с другой стороны, применимо к реальности, оно напоминает мне большую бюрократичную неповоротливую машину.

По-настоящему крупных проектов не делал, и поэтому мне интересны ваши мнения и опыт, спасибо за внимание )

Да, классы работают медленее функций но сейчас куда дороше время програмиста чем милисекунды сервера, да и вобще если нужен высоконагруженый проэкт то php тут явно не катит. В любом случае вы проэкт будете обновлять, доделывать и простые функции и глобальные переменые вас очень запутют и замедлят. Как показывает практика производители cms, форумов и прочих движков не брезгуют классами и используют их по полной, и скажу честно в них куда проще разбиратся. НО то что я сказал ранее не значит что от функций нужно отказатся и классы должны быть везьде, это даже не вопрос скорости работы скрипта, это вопрос здравой логики. Например я никогда не понимаю людей которые делают класс для класса. Тоесть если существует класс для работы с бд mysqli/PDO то писать класс обёртку для него точно не стоит, усли уж сильно нужен синглтон то я всегда обходился функцией.

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

OrmaJever, Согласен, ООП нужно использовать оправданно.
Для примера, который я привел выше (товар - ингридиенты), ООП как раз очень подходит по концепции
Как я уже сказал, в простой операции при тестрировнии разница составляля порядок, ав более крупных проектов и при нагрузке, даже не знаю сколько.
На счет крупных проектов. Я не спец в таких языках, как Java или C#, но, речь идет
о веб-сервисах в принципе, (не имеет значения, php, Java, или C#), то есть вся нагрузка и бизнес логика ложится на сервис (модель), а не клиента. Не расточительно ли в таком случае использовать ООП в полной ее мере?

OrmaJever, Использовали бы Вы ООП в том виде который я привел выше для того конкретного примера?)

единственное обьяснение разницы на порядок - кривые руки разработчика.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

вот пример криворукости

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Так речь и идет о целесообразности применения концепций ООП, когда каждая сущность отвечает сама за себя (в данном случае объект "ингридиент")

не вижу никакой связи между концепцией ООП и сотней запросов в БД. Не говоря уже о том на фига тащить на клиента сотню объектов - юзер уснет пока дочитает страницу с таким количеством.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Да, хотя бы потому что сказу при запуске не будет милионого онлайна, а со временем код всёравно будет оптимизироватся.
И опять же насчёт скорости, всё зависит от железа сервера и от остального кода. Всёравно основную часть времени будут забирать запросы в бд и сложные вычисления. Ну тоесть сами создания обьектов, вызовы методов займут предположим 2мс, а запросы и вычисления 100мс, дак есть ли смысл смотреть на эти 2мс на фоне 100?

-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.

Ну это был пример, на счет сотни объектов, может набор понадобится не для юзера а для дальнейших расчетов. Свяь ООП и сотней запросов к БД в данном случае следующая.
Всю логику, связанную с ингридиентами, я помещаю в класс "Ингридиент". В классе "Продукт" я хочу получить список его ингридиентов, класс "Продукт" не хочет и не должен знать как работает класс "Ингридиент", стороны его технической реализации, он просто говорит, "Дай информацию".

Может я где-то ошибаюсь, тогда подскажите, как технически, конкретно, вы решили бы пример, приведенный мной, с ипользованием классических понятий ООП?

очень нечасто бывают расчетв которые нельзя выполнить на стороне сервера БД.


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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

caballero Да, я тоже о подумал о создании объектов на основе уже загружженых данных, но задался вопросом, кто должен их загружать, то есть объект "теряет независимость" и появляется посредник.



Хм... "фабричный статический метод", интересно, кажется примерно понимаю, то есть объект "Продукт" передает массив ID ингридиентов статическому методу класса "Ингридиент", он свою очередб берет одним запросом данные из БД и на основе их строит объекты, так?

не так.
откуда у продукта массив ID инградиентов? Это у инградиента есть ID продукта к которому он принадлежит. Классическая связь один ко многим.

по этому продукт говорит - верни мне массив инградиентов по такому то критерию - вот мой ID.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Тогда получается классс "Ингридиент" зависит от класса "Продукт", что не совсем логично, те же ингридиенты могут быть составляющими не только объекта "Продукт" но и объекта "Склад", тогда в классе "Ингридиента" надо писать еще обработичк для Склада.
Это у продукта есть ID ингридиентов, которые входят в его состав.
Ну это не принципиально в данном случае. Спасибо за наведение в правильную сторону )
(Добавление)
[quote=Moreo]

Тогда получается классс "Ингридиент" зависит от класса "Продукт", что не совсем логично, те же ингридиенты могут быть составляющими не только объекта "Продукт" но и объекта "Склад", тогда в классе "Ингридиента" надо писать еще обработичк для Склада.
Это у продукта есть ID ингридиентов, которые входят в его состав.
Ну это не принципиально в данном случае. Спасибо за наведение в правильную сторону ) (я про фабриный статический метод

он ни от чего не зависит.


мы разбирали упрощенный пример
в реальности будет связь многие ко многим но сути дела не меняет - будет немного другой SQL запрос


нету у него ничего - есть связь между таблицами в БД. Зачем тащить список ID исли можно получить связанные данные по ID продукта который и так под руками

(Отредактировано автором: 15 Апреля, 2013 - 23:25:03)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore