ООП vs функции

ооп дает удобство разработки и изменения кода

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

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

Простота поддержки и расширяемость vs скорость

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

По барабану крупный/мелкий проект, кол-во разработчиков и проч. Эти сложности другими методами разруливаются.

ООП vs функции - это стиль, образ мыслей разработчика, та модель задачи, которая у него в голове вариться.

Катить(колесо) - функция

Колесо.катить() - ООП

:)

Не совсем так примерно половина ресурсов это работы над общим ядром, т.е. как бы один проект.

WhiteSmartFox, и на чьи деньги это происходит? компании платят netcraker-у за развитие чужого кода вместо нужного клиенту ? ей богу лучше тогда 1c внедрять. там хотя бы такой наглости не бывает.

ну, это если вы не приврали насчет ядра.

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

Катить(колесо) - функция

Колесо.катить() - ООП

---

+1 это гениально :) в холиваре участвовать не стану ибо это дело не благодарное и смысла в нем нет.

Совершенный код С. Макконнелл а ошибка по Фрейду ))

UPD: уже это отметили.