Сырая мысль, зародилась только что. Современные средства рефлексии (reflection), будь то средства дотнета, джавы или скриптовых языков, идеологически предназначены для анализа реализации (т.е. получения ответов на вопросы "каков тип объекта, какие методы есть у объекта, какие параметры у метовод" etc.)

Представляется интересным некоторое средство анализа архитектуры (ответы на вопросы вроде "что инкапсулирует этот объект — данные или действие? если данные, какова их модель? какова идеология доступа? если действие, каковы его пред- и пост-условия? с какими объектами взаимодействует этот объект?" и т.п.)

Пример в псевдокоде (Ruby-образном, как водится):

def report_formatter(arg)
  assert arg.meta.designed_as(Data)
  case arg.meta.data_model
    when Array: #выводим список
    when Matrix: #выводим таблицу 
    when Tree: #выводим дерево
    when SingleValue: #просто печатаем значение
  end
end

При этом, "архитектурная рефлексия" позволяет униформно работать с совершенно разными данными, соответствующими модели Array: и с индексируемыми числом (например arg.size, arg[i] — или же arg.children.get_count, arg.children.get_by_index(i) ) и с внешним итератором в стиле C++, и с внутренним итератором и yield — функции report_formatter это просто по-ба-ра-ба-ну.

Зачем это все нужно? Например, для легкой интеграции разнообразных библиотек без толстого-толстого abstraction layer. Например, для работы с БД есть ODBC, есть Perl::DBI и т.п. — а ведь достаточно описать "модель" библиотеки "эта функция требует на вход путь к БД и возвращает объект с моделью данных Курсор". Точнее, модель-то можно описать и сейчас. Как можно прикрутить к C++ и даже к C какую-то рефлексию. А хочется — некоего "рантайма", в котором все это происходило бы само собой.

Как-то так. Объясняю путанно, я в курсе.