Мне вся эта конструкция очень напоминает идеи Александреску о параметризации политиками. Нужно только рассматривать класс как интерфейс модуля, а «инжектируемые» через параметры шаблонов политики — как интерфейсы модулей-зависимостей (которые, возможно, тоже параметризованы, и т. д.). Возможность задания параметры по умолчанию даёт «стандартные» реализации. Схожее торжество неявных интерфейсов — концептов.
Но у вас C, а не C++. Да и с инкапсуляцией у подхода Александреску явные проблемы: все детали реализации вылезают в клиентский код.
А я могу только поддержать ребят. Я не вижу ничего плохого в изобретении собственных микро-языков, разве не на этой идее построена половина UNIX?
Наличие собственной системы сборки, помимо очевидных недостатков, имеет и значительные преимущества: её можно развивать именно в том направлении, которое действительно важно, и принимать именно те технихнические решения, которые наиболее удобны и логичны в конкретной ситуации, не гонясь за абсолютной универсальностью.
Пытаюсь сейчас построить очень похожую модульную систему в организации, выпускающей линейку продуктов, но очень быстро встал вопрос о транзитивных зависимостях. К примеру, каждый модуль имеет свой набор тестов, для сборки и выполнения которых нужен соответствующий фреймворк. Получается, некая управляющая система должна сообщать модулям при сборке, где искать модули-зависимости.
В maven этот вопрос решается наличием локального репозитория модулей, и все сборки проходят через этот репозиторий, а транзитивные зависимости выкачиваются в него прозрачно для разработчика. Мне этот вариант не очень по душе, т.к. сборки получаются менее воспроизводимыми и герметичными, иногда проект сложно собрать «с нуля».
Но у вас C, а не C++. Да и с инкапсуляцией у подхода Александреску явные проблемы: все детали реализации вылезают в клиентский код.
Наличие собственной системы сборки, помимо очевидных недостатков, имеет и значительные преимущества: её можно развивать именно в том направлении, которое действительно важно, и принимать именно те технихнические решения, которые наиболее удобны и логичны в конкретной ситуации, не гонясь за абсолютной универсальностью.
В maven этот вопрос решается наличием локального репозитория модулей, и все сборки проходят через этот репозиторий, а транзитивные зависимости выкачиваются в него прозрачно для разработчика. Мне этот вариант не очень по душе, т.к. сборки получаются менее воспроизводимыми и герметичными, иногда проект сложно собрать «с нуля».
А как вы решили этот вопрос?