Я счастлив быть первыми людьми, которые не согласны с подходом "одна структура, чтобы управлять ими всеми".
Я считаю, что инженеры должны использовать правильные инструменты (доступны) для решения проблемы.
Поверьте, это хорошее слово, так как каждый подход / методология разработки программного обеспечения имеет большое количество «верующих», за которыми следует значительное количество пессимистов:)
Но, возвращаясь к вопросу ... Я вижу 2 основных недостатка рамочного подхода:
1) Это может быть излишним
Иногда вам просто нужно простое решение для простой проблемы. Вам не нужен инструмент, который решает / связывает с решениями для всех проблем человечества.
2) «Если вы не пользуетесь, вы против нас»
Дело в том, что невозможно обеспечить большую, зрелую структуру оптимальных / простых / адекватных решений для всех проблем, которые она пытается решить. Поэтому иногда вам нужно ввести внешний инструмент. Это может быть проблемой в ... Например, вызов сигналов Qt из потоков, не являющихся qt, не работает "из коробки" (не удалось заставить его работать вообще). В этом случае вы можете столкнуться с «рамками». Вместо того, чтобы облегчить себе жизнь, вы можете захотеть нанести серьезный вред себе / другим людям:)
Одна из причин двух предыдущих пунктов заключается в том, что действительно сложно не делать предположений.
Каркасы часто делаются на многих предположениях, что программист будет делать / использовать A, B, C ... стандартный / каркасный компонент. После того, как введены жестко запрограммированные предположения, вероятность того, что каркас будет модульным, падает как пианино с 10-го этажа :)
С другой стороны, подход «правильный инструмент для решения проблем» позволяет программисту сосредоточиться на одной проблеме и хорошо ее реализовать. Говоря хорошо, я имею в виду:
1) Данные независимы
Например (C ++), если вы работаете со строками, не предполагайте строковый тип. Разрешить пользователю работать с разными строками из разных сред: QString, wxString, std :: string ...
2) Независимость от политики / расширяемая
Программисту может понравиться общий способ реализации фреймворками чего-либо, но он может обнаружить, что один крошечный аспект делает фреймворк непригодным для него. Вот почему пользователь фреймворка должен иметь возможность вводить свою собственную политику в некоторых ключевых частях
Примером семейного совместного использования этого подхода являются внутренние / внешние реализации DSL (предметно-ориентированный язык). Конкретным примером (C ++) является библиотека Blitz ++.
Все, что я сказал ранее, также относится к языкам высокого уровня. Например, на виртуальной машине Java могут существовать языки (для начала Scalla).
Надеюсь, я сделал несколько хороших замечаний.
С наилучшими пожеланиями,
Marcin