Здравствуйте, Joker6413, Вы писали:

J>ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач... Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...
Основная проблема существующего ООП — это статичность объектной модели.
Сила концепций инкапсуляции и наследования в том, что можно "поделить" предметную область на некоторые подобласти (ну, скажем, неймспейсы), которые взаимодействуют между собой не "каждый с каждым". Внутри каждой области можно выделить еще более мелкие сущности и т.д.
Это и есть единственный известный на данный момент способ контроля сложности.
Собственно, забегая немного назад, сложность и выражается в том, что в произвольно взятом наборе из N сущностей возникает ~N^2 двуместных связей.
Потому задача современного программирования — сделать так, чтобы каждая сущность взаимодействовала не более чем с десятком других. Неважно, что это будет — класс, объект, модуль, домен или еще что-то. Каждая "окрестность" должна быть невелика.
Так вот проблемы-то возникают в основном из-за того, что
а) понимание предметной области меняется в процессе проектирования/разработки (идентифицируются новые сущности, или возникают новые связи). К несчастью, современное коммерческое программирование не позволяет потратить пару тысяч лет на поиск наиболее адекватной модели чего бы то ни было.
б) сама предметная область меняется в процессе проектирования/разработки/эксплуатации приложения.

Таким образом, модель должна успевать за изменением условий. Иначе она теряет свою адекватность, и появляются заплатки и исключения. Вначале удается поддерживать корректность, но сложность начинает неконтролируемо расти, а это затрудняет поддержку корректности.

Два основных подхода, известных мне, это статический и динамический.

При статическом подходе мы пытаемся добавлять новые уровни абстракции в модель. Раньше вся модель сводилась к описанию классов, а всякие рутинные вещи типа VMT и размеров генерил компилятор. Теперь мы придумываем, например, шаблоны, и компилятор начинает генерировать классы, для которых он генерирует VMT и все такое. Дальше мы придумываем UML и тул, который генерирует эти шаблоны...

Динамический подход (ака рефакторинг) расширяет эту технику, предоставляя нам удобную возможность изменить модель на произвольно взятом уровне. Например, разделить монолитный класс на два — предка и наследника, чтобы дать возможность отнаследоваться "повыше" в дереве. Или объявить часть класса интерфейсом, вынести его наружу... Все это с сохранением корректности уже написанного кода, т.е. если уж мы вынесли что-то в интерфейс, то тот код, который раньше пользовался ссылкой на наш класс, должен (если подмножество использованных методов соответствует) теперь брать ссылку на интерфейс. И т.п.

Лично я думаю, что развитие средств поддержки этих подходов и будет генеральной линией партии на ближайшие пару десятков лет.