模块化架构设计原则：高内聚低耦合、接口隔离、依赖倒置、模块划分方法论
模块化架构，说白了就是「拆」的艺术。但怎么拆、拆到什么粒度、拆完怎么拼回去，这里面门道很深。我做了十几年嵌入式系统，见过太多「拆完反而更乱」的项目——模块之间你中有我、我中有你，改一个地方崩一片。
这一章，咱们就聊聊模块化设计的四个核心原则。这些原则不是纸上谈兵，是我在多个嵌入式项目中踩过坑、填过土之后，真正觉得管用的东西。
高内聚与低耦合：模块化的基石
这两个词你肯定听过。但什么叫「高」？什么叫「低」？有没有量化标准？
我个人的理解很简单：高内聚，就是一个模块只干一件事，而且把这件事干好。低耦合，就是一个模块出问题，其他模块不受影响。
内聚与耦合的量化参考
| 指标 | 高内聚表现 | 低耦合表现 |
|---|---|---|
| 模块内部函数调用 | 80% 以上调用在模块内部完成 | 对外暴露接口不超过 5 个 |
| 模块间数据传递 | 通过结构体指针，而非全局变量 | 无直接内存共享 |
| 修改影响范围 | 修改内部实现，不修改接口 | 修改一个模块，最多影响 2 个其他模块 |
我在一个车载信息娱乐项目中遇到过反面教材。当时有个「系统管理模块」，既管电源、又管日志、还管 OTA 升级。三个功能混在一起，每次改电源策略，日志那边就出 bug。后来我硬是拆成三个独立模块，每个模块只干一件事，问题立刻少了 70%。
接口隔离原则：别让调用方依赖它不需要的东西
这个原则，说白了就是「接口要小，职责要单一」。你想想看，一个驱动接口如果同时提供 open()、read()、write()、ioctl()、mmap() 五个方法，但调用方只需要 read() 和 write()，那这个接口就是「胖接口」。
胖接口的问题在于：你改了 ioctl() 的实现，所有依赖这个接口的模块都得重新编译、重新测试。哪怕它们根本没用 ioctl()。
接口隔离的实践技巧
- 每个接口文件只暴露 3-5 个函数
- 用
struct ops方式组织接口，调用方只注册自己需要的函数指针 - 接口参数尽量用基础类型，避免传递复杂结构体
我记得有个项目做传感器驱动，一开始把所有传感器的操作都塞进一个 sensor_ops 结构体里。温度、湿度、气压、加速度，全混在一起。后来我改成每个传感器类型一个独立的 ops 结构体，调用方只拿自己需要的那个。编译时间从 3 分钟降到 40 秒，测试用例也少了一半。
依赖倒置原则：高层模块不依赖底层细节
这个原则听起来有点绕。我换个说法：抽象不依赖具体，具体依赖抽象。
在嵌入式 Linux 里，最常见的应用就是「驱动抽象层」。你写应用层代码时，不应该直接调用 i2c_read() 或 spi_write()，而是调用一个抽象的 bus_read()。底层是 I2C 还是 SPI，由配置文件决定。
/* 反例：直接依赖具体总线 */
int read_temperature(void) {
return i2c_read(0x48, 0x00); // 硬编码 I2C
}
/* 正例：依赖抽象接口 */
int read_temperature(void) {
return bus_ops->read(bus_ops->handle, 0x00);
}这样做的好处是什么？我举个例子。有个项目原本用 I2C 连接温度传感器，后来客户要求换成 SPI 接口的传感器。如果代码是反例那种写法，你得改所有调用 i2c_read() 的地方。如果是正例，只需要换一个 bus_ops 的实现，应用层一行代码都不用动。
依赖倒置的常见误区
- 不要为了抽象而抽象——如果系统只有一种总线，直接调用也没问题
- 抽象层不要过度设计——接口参数够用就行，别提前预留「未来可能用到的」参数
- 注意性能开销——函数指针调用比直接调用多一次间接寻址，在热路径上要谨慎
模块划分方法论：从业务到代码的映射
原则讲完了，怎么落地？我总结了一套模块划分的「三步法」。
- 业务域分析：把系统功能按业务领域分组。比如「音频处理」「网络通信」「用户界面」各是一组。
- 依赖关系梳理：画出模块间的调用关系图。箭头方向从调用方指向被调用方，尽量让箭头单向流动。
- 接口定义：为每个模块定义清晰的输入输出接口。接口参数要少，语义要明确。
下面这张图展示了一个典型的嵌入式 Linux 模块划分结构：
你看，这个结构里每一层只和相邻层通信。应用层不直接调驱动，驱动层也不关心上层业务。这就是「分层隔离」的典型做法。
模块划分的避坑指南
我曾经在一个项目中把模块划分得「太细」了。一个温度传感器驱动拆成了「初始化模块」「读取模块」「校准模块」「休眠模块」四个文件。结果呢？一个简单的温度读取操作，要跨四个文件、调六个函数。代码可读性极差，调试时跳来跳去，最后我不得不合并回去。
模块划分的常见坑
- 粒度太细：一个功能拆成十几个文件，反而增加维护成本
- 循环依赖：模块 A 调模块 B，模块 B 又调模块 A，编译时死循环
- 接口膨胀：一个模块暴露几十个接口，调用方根本不知道用哪个
- 过度抽象：为未来可能不存在的需求提前设计抽象层，浪费开发时间
我的建议是：先粗后细，迭代调整。第一版先按业务域分成 5-8 个大模块，跑通后再根据实际需要拆分。别一开始就追求「完美划分」，嵌入式项目最怕过度设计。
小结
模块化设计不是一蹴而就的事。高内聚低耦合是目标，接口隔离和依赖倒置是手段，模块划分方法论是落地工具。这四个原则配合使用，才能做出真正可维护、可扩展的嵌入式 Linux 系统。