我正在从 Robert C. Martin 的书 Clean Architecture 中学习架构。本书强调的主要规则之一是 DIP 规则，该规则规定源代码依赖项必须仅指向内部，指向更高级别的策略。试图在嵌入式域中翻译它假设有 2 个组件 scheduler 和 timer 。调度器是依赖于低级计时器驱动程序的高级策略，需要调用 API get_current_time() 和 set_timeout() ，简单地说，我会将模块拆分为一个实现文件 timer.c 和一个 header (一个接口(interface)？) timer.h 和 scheduler.c 可以简单地包含 timer .h 以使用这些 API。阅读这本书将前面的场景描述为打破依赖规则，并暗示应该实现两个组件之间的接口(interface)以打破依赖。
例如在 c 中模仿 timer_abstract 可以包含一个带有函数指针的通用结构
结构 timer_drv {
uint32 (*get_current_time)(void);
void (*set_timeout)(uint32 t);
}
这对我来说看起来像是过度设计。一个简单的头文件还不够吗？一个 C 头文件可以被认为是一个接口(interface)吗？
在计算中，“接口(interface)”是两个或多个组件或子系统交换信息的公共(public)边界。
C 或 C++ 中的头文件是包含一组声明和(可能)宏的文本文件，这些声明和(可能)宏可以插入编译单元(一个单独的源代码单元，例如源文件)，并允许该编译单元使用这些声明和宏。换句话说，源文件中的 #include "headerfile" 在后续编译之前由 C 或 C++ 预处理器替换为 headerfile 的内容。
根据这些定义，我不会将头文件描述为接口(interface)。
头文件可以定义数据类型、声明变量和声明函数。多个源文件可能包含该 header ，每个源文件都可以使用该 header 中声明的数据类型、变量和函数。一个编译单元可能包含该 header ，然后定义 header 中声明的部分(或全部)函数。
但是类型、变量和函数不需要放在头文件中。一个有足够决心的程序员可以手动将声明和宏复制到每个使用它们的源文件中，而从不使用头文件。 C 或 C++ 编译器无法区分 - 因为预处理器所做的只是文本替换。
声明和宏的逻辑分组实际上代表了一个接口(interface)，而不是编译单元可以使用有关接口(interface)的信息的方式。头文件只是一种(可选的)方式，通过它可以使编译单元可以使用一组声明和宏。
当然，头文件通常用于避免在使用一组声明和宏时出错 - 因此可以帮助更轻松地管理由这些声明和宏表示的接口(interface)。 #include头文件的每个编译单元接收相同的内容(除非受到其他预处理器宏的影响)。这比程序员手动将声明复制到每个需要它们的源文件中更不容易出错。它也更易于维护 - 编辑头文件意味着可以重建所有编译单元并可以看到更改。然而，手动更新每个源文件中的声明和宏可能会引入错误，因为程序员很容易出错 - 例如，在源文件之间编辑不一致的声明。