ООП или не ООП

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

Да, в десятках и сотнях тысяч готовых классов в .NET или Java легко запутаться, но они позволяют не разрабатывать реализуемые ими вещи самим. Объектно-ориентированные языки программирования дают возможность оперировать более высокоуровневыми понятиями и не тратить время на возню с памятью напрямую (от утечек правда это не избавляет, но все же), указателями, типовыми алгоритмами, реализацией протоколов и прочими нормальными для низкоуровневых языков программирования вещами. Уделяя меньше внимания деталям, можно создавать крупные проекты большими мазками - возможно в ущерб качеству, но для многих ситуаций это приемлемо.

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

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

Плюс не стоит забывать и о том, какие люди участвуют в разработке: бывают разработчики, которые фанатеют от ООП, всю жизнь занимаются "сборкой" проектов из библиотек на Java или C#, являются ярыми поклонниками TDD, а бывают разработчики, которые предпочитают Assembler/C/Fortran/Cobol/Lisp/Haskell/Erlang (нужное подчеркнуть), любят реализовывать очень сложные алгоритмы, оптимизировать их, добиваясь выигрыша в несколько миллисекунд во времени или пару килобайт в использованной оперативной памяти. Естественно это лишь крайние или почти крайние случаи, большинство разработчиков скорее всего находятся где-то посередине (к сожалению, у меня нет такой статистики).

Копайте ямы лопатами и забивайте гвозди молотками, а не наоборот :-).