440hz
Дело в том, что ты не первый (из людей, у которых есть опыт и кому можно доверять в подобном вопросе) говоришь, что проще написать заново.
Я понимаю, о чем ты говоришь, когда говоришь о ресурсах. Лишнее поле - лишнее время выполнения - лишняя нагрузка на сервер - лищнее занимаемое дисковое пространство.
Мне только не совсем понятно, почему те, кто борется за ООП, как одну из заслуг ООП ставят возможность повторного использования кода, а когда речь доходит до реальных проектов, то почему-то начинают говорить, что проще написать заново?
Я же использую у себя процедурный подход из тех соображений, что подавляющее большинство задач, решаемых на РНР, строятся по одной из двух схем: 1) пришли данные - записали - вывели сообщение и 2) пришли данные - вывели данные. В очень редких случаях возникает необходимость моделирования сложных объектов. Например, прямо сейчас я могу припомнить работу с мылом, мастер оплаты (это как в винде есть несколько окошек, где пользователю задают вопросы и он может между ними ходить, нажимая вперед-назад и после последнего окошка выполняется действие - оплата выбранным способом в выбранной валюте и т.п.). Но это очень-очень редкие случаи.
Так вот, я, используя процедурный подход, совершенно-абсолютно согласен, что код дожен быть простым, понятным и его можно было использовать повторно. Но отличие меня, использующего процедуры от тех, кто используют ООП (я не говорю за всех, но такие, кажется, встречаются очень часто) в том, что при решении реальных задач я продолжаю думать, что "код нужно использовать повторно", а они почему-то теперь отказываются от мысли о повторном использовании кода, мотивируя это "хлопотами и кликами в настройках самого модуля".
У меня все настройки вынесены в отдельный файл. Но даже этот файл не нужно изменять для новых проектов - для каждого проекта есть собственный файл настроек, который переопределяет все настройки по умолчанию. При рассылке обновлений, даже если у меня добавились новые настройки - я не должен заново настраивать инсталяции у всех клиентов - я просто рассылаю новые библиотеки, и какая-то настройка останется включенной по умолчанию. Надо будет изменить именно эту настройку в конкретной инсталяции - изменяем именно эту настройку. Никаких затруднений я с настройками не испытываю.
Что еще интересно, противники ООП обычно говорят, что объекты - тормознутее процедур и функций. Вон даже в статье по приведенной выше ссылке подобная мысль высказывалась. Я, используя функции, вообще говоря, сомневаюсь, что эта "тормознутость" сколько-нибудь значительна; использовать процедуры вместо ООП из соображений скорости - это значит экономить на спичках; я использую процедуры исключительно_только потому, что ООП мне не видится нужным (в большинстве задач). Но мне почему-то кажется, что стремление к экономии ресусов за счет удаления нескольких условий (какие из полей показывать, а какие - нет) и за счет удаления нескольких полей (пустой blob, если я не ошибаюсь, занимает 4 байта на запись) - это тоже экономия на спичках. Несравнимо больше ресурсов уходит из-за непродуманных алгоритмов, запросов, неправильно расставленных индексов.
Один из моих шефов, которого я считаю очень мудрым шефом, часто советовал оставлять в базах данных дополнительные поля на "всякий случай" - у него очень много опыта и он говорит, что много раз сталкивался с тем, что эти дополнительные поля потом приносят дополнительное облегчение при добавлении новых фич. Я с этим не совсем согласен, и оставляю в базах данных только те поля, которые реально используются хотя бы в одном проекте. Но я не стремлюсь оптимизировать базу данных так, чтобы в каждом проекте быле те и только те поля, которые используются в этом проекте.
При моем подходе, когда у меня для всех инсталяций используется единая, например, служба новостей, найдя глюк в этой службе и исправив его один раз, я рассылаю новую инсталяцию всем и радуюсь - теперь у всех этого глюка не стало. При Вашем подходе, когда у всех - свое, мне не достаточно исправить этот глюк однажды, я дожен исправлять во всех проектах.
А еще мое внимание привлек такой вопрос: вы действительно считаете, что сделать клики в настройках модуля - это сложнее, чем написать модуль с нуля? Может, Вы как-то не так модули пишете, что их настрока столь сложна? У меня никогда никаких проблем с настройками не было и я как-то не думал, что они могут возникнуть.
Возможно, у меня не слишком много опыта - моя система исползуется каких-то тройку лет в каком-то десятке систем с очень низкой посещаемостью и поэтому я не вижу каких-то проблем с неиспользованием оптимизации в стиле "написать с нуля"? Если Вас это не затруднит - опишите как можно подробнее, какие именно хлопоты возникают, какие именно ресурсы тратятся и в чем состоит сложность настройки. А я потом склепаю статью для фака - я думаю, этот вопрос был бы интересен многим.
Есть много попыток создания "универсальной" CMS, но IMHO до такого ещё как до Пекина [зацензурено мной]