Я хотел бы знать, как хороший встроенный SW-архитектор выберет лучший вариант для использования одной и той же части кода в разных модулях C-файлов, когда эти модули находятся на разных уровнях архитектуры.
Каждый модуль представляет собой файл .c с внутренними и внешними функциями с соответствующим файлом .h с объявлениями открытых функций.
У меня 1) модули низкого уровня, 2) модули среднего уровня, 3) модули высокого уровня и 4) модули уровня приложения. Где 4) вызовы 3) функции, 3) вызовы 2) функции и т. Д.
Но я понял, что некоторые из функций 1), 2) и 3) выполняют одни и те же инструкции в разных точках своих процедур. Каков наилучший вариант для создания хорошего и эффективного проекта архитектуры кода, если часть кода в некоторых 1) подпрограммах также присутствует в подпрограммах некоторых 2) и 3) модулей?
Моя первая мысль - упаковать набор команд в public function_x и объявить его в заголовочном файле для вызова функций модулей верхнего уровня. Как архитектор я узнал:
- думать о заголовочных файлах file_x.h как о модульном API, который можно увидеть и использовать для других и верхних файлов (единственный интерфейс, взаимодействующий между модулями).
- Если функция API используется как внутренняя функция в том же модуле file_x.c, который их реализует, это не очень хороший дизайн.
- т.е. 4) модули не могут напрямую взаимодействовать с 1) модульным API. 4) функция модуля может вызывать только 3) функцию API модуля, 3) функция модуля может вызывать только 2) функцию модуля; следовательно, 2) функция модуля может вызывать только 1) функции модуля.
Дело в том, что я унаследовал старый проект, и они записали байт с помощью цифрового выхода, отправив байт по последовательной шине на потенциометр. Но они реализовали и объявили одну и ту же функцию с тем же именем, что и внутренняя функция в каждом модуле / файле. В других случаях я обнаружил, что они переписывают этот код внутри других подпрограмм, где я просто вызываю подпрограмму вместо. Я думал, что это может быть улучшено.
Итак, мои сомнения:
Является ли хороший дизайн для упаковки инструкций, установленных в функции на 1) уровне модуля, и вызова из остальных модулей уровней?
Лучше ли, если 2) модуль уровня также упаковывает функцию модуля 1), давая другое имя и перенося его в свой заголовок API, готовый для использования для функций модулей 3 уровня?
Что делать, если я также использую код в разных модулях, но они принадлежат к одному уровню модулей?
Как вы относитесь к дизайну, если ту же функцию необходимо использовать как внутреннюю функцию и в то же время вызывать другие файлы как открытую функцию.