Вчера мне на почту пришло письмо от коллеги с просьбой прокомментировать статью, видимо его же перевода или авторства, о судьбе объектно-ориентированного программирования в современном мире: Почему объектно-ориентированное программирование провалилось?. Собственно говоря, пишу ответ в своем блоге скорее чтобы несколько растопить образовавшийся здесь лед, да и возможно снова затянет - продолжу дальше активно писать в Insight IT.
Для начала хочу вкратце пересказать саму статью. Написана она по мотивам мнений различных экспертов в области разработки, в частности Objects Have Failed by Richard P. Gabriel, November 6, 2002 и holywar'а на конференции OOPSLA с участием именитых специалистов. Аргументы у обоих сторон "за и против" были довольно странноватыми и по сути были подтверждениями и опровержениями различных мифов об ООП, например о том, что с использованием парадигмы ООП разработка идет быстрее/проще/понятнее/удобнее, что ОО языки программирования не соответствуют требованиям вычислительных процессов будущего и не адекватно отражают предметную область, что повторное использование кода есть в любом языке программирование - как минимум в виде библиотек. Сторонники ООП же в основном настаивают на справедливости мифов и твердо отстаивают три основных столпа их парадигмы. На вышеупомянутой конференции по мнению аудитории вверх взяла сторона "против ООП" из-за натиска сторонников языка Lisp и растерянности сторонников ООП касательно своей же теории.
Что же касается моего мнения касательно данного вопроса, то я не являюсь ни приверженцем, ни противником объектно-ориентированного подхода к программированию. В целом мой взгляд на ситуацию довольно прост: все языки программирования - лишь инструмент для решения вполне определенного круга задач. Выбор инструмента и способа работы с ним определяется в основном лишь самой конкретной постановкой задачи, требованиям к ней, а также имеющимися в наличии ресурсами - в первую очередь человеческими и финансовыми. Не нужно смотреть на программирование чисто с технической точки зрения - в первую очередь программисты решают бизнес-задачи и проблемы людей, а каким именно образом и с использованием каких инструментов - заказчиков и потребителей программных продуктов волнует меньше всего. Для них намного важнее итоговые показатели получившегося продукта: себестоимость разработки и поддержки, сроки исполнения, соответствие требованиям, а также в зависимости от типа продукта масштабируемость, производительность, стабильность, безопасность.
Да, в десятках и сотнях тысяч готовых классов в .NET или Java легко запутаться, но они позволяют не разрабатывать реализуемые ими вещи самим. Объектно-ориентированные языки программирования дают возможность оперировать более высокоуровневыми понятиями и не тратить время на возню с памятью напрямую (от утечек правда это не избавляет, но все же), указателями, типовыми алгоритмами, реализацией протоколов и прочими нормальными для низкоуровневых языков программирования вещами. Уделяя меньше внимания деталям, можно создавать крупные проекты большими мазками - возможно в ущерб качеству, но для многих ситуаций это приемлемо.
Когда речь идет о разработке крупной корпоративной системы с большим количеством пользователей и разнородной информации, на первый план выходят чаще всего масштабируемость и сроки реализации, а вовсе не производительность и эффективность алгоритмов. В таких системах разработка выглядит скорее как склейка требуемого продукта из различных готовых компонентов, чем реализация собственных алгоритмов и оптимизация производительности. Для подобных проектов чаще более уместен объектно-ориентированный подход с использованием широкого спектра готовых классов, библиотек и системных компонентов. Да, в данном случае пострадает производительность, но купить несколько дополнительных серверов дешевле, чем изобретать велосипед и писать с нуля реализацию всех необходимых составных частей системы.
Если же разрабатывается скажем какая-нибудь библиотека для расчета инверсной кинематики, то скорее всего использование ОО-подхода в ней будет излишним и после реализации всех алгоритмов на низкоуровневом языке в функциональном/процедурном стиле будет достаточно создать обертки для всех требуемых языков программирования.
Плюс не стоит забывать и о том, какие люди участвуют в разработке: бывают разработчики, которые фанатеют от ООП, всю жизнь занимаются "сборкой" проектов из библиотек на Java или C#, являются ярыми поклонниками TDD и Agile-разработки, а бывают разработчики, которые предпочитают Assembler/C/Fortran/Cobol/Lisp/Haskell/Erlang (нужное подчеркнуть), любят реализовывать очень сложные алгоритмы, оптимизировать их, добиваясь выиграша в несколько миллисекунд во времени или пару килобайт в использованной оперативной памяти. Естественно это лишь крайние или почти крайние случаи, большинство разработчиков скорее всего находятся где-то посередине (к сожалению, у меня нет такой статистики), предпочитая универсальные языки программирования, на которых можно писать код как объектно-ориентированно, так и нет (C++/Python/PHP/etc). Хочется порекомендовать руководителям не заставлять имеющихся в наличии людей заниматься тем, что им не по душе, просто так как Вам кто-то вчера рассказал, что "Ruby on Rails - это круто" или так как во-о-он тот известный проект реализован с использованием во-он тех технологий, языков программирования или парадигм разработки. Используемые технологии и подходы к написанию кода, должны соответствовать поставленным задачам, а команда должна быть готова реализовать проект именно так, как это необходимо, при этом очень большое значение имеет распределение ролей между разработчиками - чтобы каждый занимался своим любимым делом.
Коллеги, копайте ямы лопатами и забивайте гвозди молотками, а не наоборот :)
