Никто никогда не говорил, что ООП - для дурачков. Это инструмент для профессионалов, которые знают что делают и для чего.

Если использовать бездумно - факт. Ну вот на кой было создавать по объекту на каждого юзера? А потому что это сущность. Он так рассуждал. А раз сущность, значит должен жить автономно, своей жизнью. Должен иметь внутри себя необходимые данные. А где взять? Да запросом же, все просто. Но когда потребовалось сто анкет на странице, потребовалось и сто объектов. А значит и сто запросов.

Сделать один запрос с IN - это нужно было менять архитектуру. А на кой, ведь нарушится принцип, юзер перестанет быть сущностью.

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

Да а кто против то. Я же написал:

Другой вопрос, что ошибочно считается, что ООП, это серебряная пуля. А это не так.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Не надо утрировать. Да, я считаю проект over деситялетней давности устаревшим. Но для ИТ даже 2-3 года огромный срок и успешный сайт за это время претерпит сотни изменений. Насколько они будут трудоёмкими зависит от архитектуры. Я не отступлюсь: невозможно потроить слабосвязанный модульный проект, без применения ООП.

Нет, это не серебряная пуля, разумеется. И не панацея. Просто возможность построить легочитаемый и легко расшияемый/модифицируемый код. Если задача формулируется как экономия компьютерных ресурсов и на это готоы тратить большой бюджет - дело другое. Непонятно зачем, ведь процессорное время стоит в десятки раз дешевле времени человеческого. Гораздо дешевле наращивать мощность, чем нанимать дополнительных программистов.

Про SQL запросы я и вовсе не понял, это видимо прикол был.

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

Кроме того, нельзя их противопоставлять. Программистов и сервера. Программистам платить придется в любом случае, это не фриланс "сделал-отдал". Работы полно постоянно и оклад прогеру быть обязан. А вот докупать дополнительный сервер - совсем не обязательно.

Что касается этого:

да, так и есть. Но дело в том, что нет большой разницы - расширять существующий функционал или дописывать новый. По моему опыту второе как раз проще. А устаревший просто выкидывать. И раз в два три года делать полную ревизию.

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

Вообще ООП помогло мне устроится на работу. Это как Черчиль говорил - "Своим долголетием я обязан спорту. Потому что никогда им не занимался."

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

149 файлов без кэша, 136 с кэшем. И это норма.

Зачем все эти выпады в мой адрес? Я что тут единственный кто нормально умеет применять ООП? С таким же успехом я могу сказать, что ты фанатик процедурки. Короче не надо так.

Я в своём pet-проекте занимаюсь R&D. То что я переписываю свой код - это норма, ведь я применяю более эффективные, на мой взгляд, технологии. То что ты переписываешь свой код, это всего лишь смена требований заказчика, что в конечно счете означает лишь то, что твой инфраструктурный код на столько не поддается расширению, что его приходятся попросту выкидывать при каждой смене БИЗНЕС ТРЕБОВАНИЙ.

лол, естественно тут ООП виновато, инфа 146%

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

Я это нормой не считаю. Это явный перебор минимум в четыре раза. Если у меня при формировании страницы задействовано больше 30 файлов, это уже звоночек. Причем размер класса редко превышает 300-500 строк вместе с комментариями и док-блоками.

Но каждому свое, я же не настаиваю. Нравятся монстры - дело хозяйское. ZEND-фреймворк вообще не стесняется. Там на элементарный "Привет, Мир" около 5000 вызовов методов. И живут же как то.

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

Да конечно норма, я о том и писал. Это нормально, когда меняются технологии. Просто на твоем примере можно проследить динамику. А когда пишется куча разных проектов на заказ, то такие изменения происходят от проекта к проекту. И создается впечатление, что это расширение изначального функционала. На самом деле это та же оптимизация. Часто с глобальными изменениями архитектуры.

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

Здесь не о связи речь. И не о вине. Здесь речь о том, что ООП, это не верх профессионализма, как многим кажется. И освоив некоторые приемы и технологии, можно и с этой методой так наговнокодить, что придется увольняться.

А можно с точностью до наоборот. Переделать приложение так, что оно даст 20-ти кратную фору всем этим технологиям. И будет спокойно жить и работать уже больше 5 лет, принося немалую прибыль без всякого ООП.

Так что еще раз повторю:

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.