[prog.thoughts] Про ООП: создание инфраструктуры vs использование инфраструктуры

Я, конечно, не знаменитый LOR-овский anonimous, который периодически срывает покровы веселит посетителей LOR-а своими прозрениями и откровениями в отношении ООП... Но об ООП и сам время от времени задумываюсь. В частности о том, почему в последние годы все чаще и чаще слышна как критика, так и, на мой взгляд, пустые наезды на ООП. В особенности от молодых разработчиков. И вот на днях пришла в голову мысль о том, что это связано с тем, как изменилось само программирование за последние 20-25 лет.

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

Грубо говоря, ООП оправдывал себя на 100% когда нужно было создавать MFC, Qt и Swing. Но после того, как эти самые MFC, Qt и Swing были созданы, да еще и обросли кучей дополнений и расширений, остается только их использовать. И вот тут-то и оказывается, что для сборки софта из различных готовых компонентов ООП, как таковой, не очень-то и нужен. Тут более уместны различные декларативные описания логики и потоков данных, легкость композиции потоков данных и операций над ними, простота перекоммутации всего этого хозяйства при сопровождении и развитии.

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

Так что, возможно, ООП превращается в нишевую методологию, пригодную для разработки инфраструктуры, но не имеющей широкого применения при композиции готовых программных компонентов.

Причем это ощущается даже на себе. Когда делаешь большую библиотеку на C++, то в ее реализации ООП применяется в полный рост. А вот даже при написании примеров и тестов для этой библиотеки уже ловишь себя на том, что шаблоны и обычные функции используются гораздо чаще, чем наследование, инкапсуляция и полиморфизм...