В настоящий момент существует своего рода мания по поводу объектно-ориентированного программирования, однако некоторые из самых умных программистов, которых я знаю, относятся к нему с наименьшим восторгом.
Моё личное ощущение таково: объектно-ориентированное программирование — полезная техника в некоторых случаях, но это не то, что должно пронизывать каждую написанную вами программу. У вас должна быть возможность определять новые типы, но вы не должны быть обязаны выражать каждую программу как определение новых типов.
Я думаю, есть пять причин, по которым людям нравится объектно-ориентированное программирование, и три с половиной из них — плохие:
Объектно-ориентированное программирование вызывает восторг, если у вас статически типизированный язык без лексических замыканий или макросов. До некоторой степени оно предлагает способ обойти эти ограничения. (См. Десятое правило Гринспена.)
Объектно-ориентированное программирование популярно в крупных компаниях, потому что оно подходит под то, как там пишут программное обеспечение. В больших компаниях софт, как правило, пишется большими (и часто меняющимися) командами посредственных программистов. Объектно-ориентированное программирование навязывает этим программистам дисциплину, которая не даёт ни одному из них нанести слишком большой ущерб. Плата за это — раздутый протоколами код, полный дублирования. Для крупных компаний это не слишком высокая цена, поскольку их программное обеспечение, вероятно, в любом случае будет раздутым и полным дублирования.
Объектно-ориентированное программирование порождает много того, что выглядит как работа. Во времена перфорированной бумаги существовал такой тип программистов, которые помещали на страницу всего пять или десять строк кода, перед которыми шли двадцать строк тщательно отформатированных комментариев. Объектно-ориентированное программирование для таких людей — как крэк: оно позволяет встроить все эти строительные леса прямо в исходный код. То, с чем Lisp-хакер справился бы добавлением символа в список, превращается в целый файл классов и методов. Так что это хороший инструмент, если вы хотите убедить себя или кого-то ещё в том, что проделываете огромную работу.
Если язык сам по себе является объектно-ориентированной программой, пользователи могут его расширять. Ну, возможно. Или, возможно, можно сделать ещё лучше, предложив отдельные концепции объектно-ориентированного программирования à la carte. Перегрузка, например, по своей сути не привязана к классам. Посмотрим.
Объектно-ориентированные абстракции аккуратно ложатся на предметные области определённых специфических видов программ, таких как симуляции и CAD-системы.
Лично мне объектно-ориентированные абстракции никогда не были нужны. В Common Lisp есть невероятно мощная объектная система, и я ни разу ею не воспользовался. Я делал много вещей (например, создавал хеш-таблицы, наполненные замыканиями), для которых в более слабых языках потребовались бы объектно-ориентированные техники, но мне никогда не приходилось использовать CLOS.
Может быть, я просто глуп или работал над каким-то ограниченным подмножеством приложений. Проектировать язык на основе собственного опыта программирования довольно рискованно. Но куда опаснее, кажется, добавлять в него вещи, которые вам никогда не были нужны, только потому, что их принято считать хорошей идеей.