3. 模块化设计思想：高内聚低耦合原则、接口隔离、依赖倒置、模块划分方法论

模块化设计，说白了就是“分而治之”。把一个大系统拆成若干小块，每块各司其职。听起来简单，但真正落地的时候，我见过太多团队把模块化做成了“一团乱麻”。

为什么会这样？因为很多人只记住了“拆”，却忘了“怎么拆”和“拆完怎么拼”。今天我们就来聊聊模块化设计的四个核心支柱：高内聚低耦合、接口隔离、依赖倒置，以及模块划分的具体方法论。

3.1 高内聚与低耦合：模块化的基石

这两个词几乎是模块化设计的代名词。但你真的理解它们吗？

我在项目中遇到过这样一个案例：一个驱动模块里，居然混入了日志系统的初始化代码。当时为了图方便，觉得“反正都是初始化，放一起得了”。结果后来日志系统要换方案，整个驱动都得跟着改。这就是典型的内聚不够。

判断内聚高低，有个简单方法：你问自己，这个模块的改名理由是不是只有一个？如果答案是“是”，那内聚就合格了。

内聚类型	描述	评价
功能内聚	模块内所有元素共同完成一个功能	最佳
顺序内聚	元素按顺序执行，前一个输出是后一个输入	良好
通信内聚	元素操作同一数据	一般
逻辑内聚	元素通过参数选择执行不同逻辑	较差
偶然内聚	元素之间毫无关系，只是放在一起	极差

3.2 接口隔离原则：别让模块“吃大锅饭”

接口隔离原则（ISP）告诉我们：客户端不应该被迫依赖它不使用的接口。你想想看，一个传感器驱动模块，如果它的接口里包含了“播放音频”的方法，那调用者得多困惑？

我曾经接手过一个项目，一个“系统管理模块”提供了 30 多个接口，从“设置IP地址”到“播放开机音乐”全在里面。结果呢？每个调用者都只用了其中两三个接口，但整个模块一改动，所有调用者都得重新编译。这就是典型的“胖接口”问题。

正确的做法是：把接口拆细。每个接口只服务于一个特定的客户端群体。

// 不好的做法：一个接口包含太多职责
typedef struct {
    int (*init)(void);
    int (*set_ip)(const char *ip);
    int (*play_sound)(int freq);
    int (*read_temperature)(float *temp);
    int (*shutdown)(void);
} system_if_t;

// 好的做法：按职责拆分
typedef struct {
    int (*init)(void);
    int (*set_ip)(const char *ip);
} network_if_t;

typedef struct {
    int (*play_sound)(int freq);
} audio_if_t;

typedef struct {
    int (*read_temperature)(float *temp);
} sensor_if_t;

3.3 依赖倒置原则：让高层模块“说了算”

依赖倒置原则（DIP）的核心是：高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

听起来有点绕？我换个说法：你写业务逻辑的时候，不要直接调用具体的硬件驱动，而是定义一个抽象接口。这样，换硬件的时候，只需要换驱动实现，业务代码不用动。

在嵌入式 Linux 中，这个原则特别重要。因为硬件迭代太快了。我记得有个项目，一开始用的是 SPI Flash，后来要换成 NAND Flash。如果业务代码直接调用了 SPI 的读写函数，那改起来就麻烦了。但如果业务代码只依赖一个抽象的“存储接口”，那换硬件就是换一个驱动模块的事。

// 抽象接口
typedef struct {
    int (*read)(uint32_t addr, uint8_t *buf, size_t len);
    int (*write)(uint32_t addr, const uint8_t *buf, size_t len);
    int (*erase)(uint32_t addr, size_t len);
} storage_if_t;

// 高层业务模块只依赖抽象
int save_config(const storage_if_t *storage, const config_t *cfg) {
    return storage->write(CONFIG_ADDR, (const uint8_t *)cfg, sizeof(config_t));
}

// 低层具体实现
static int spi_flash_read(...) { /* SPI Flash 实现 */ }
static int spi_flash_write(...) { /* SPI Flash 实现 */ }

const storage_if_t spi_storage = {
    .read = spi_flash_read,
    .write = spi_flash_write,
    .erase = spi_flash_erase,
};

3.4 模块划分方法论：从理论到实践

理论说完了，我们来点实际的。模块到底怎么划？我总结了四个步骤：

1. 职责识别：列出系统所有的功能点，按职责分组。
2. 依赖分析：画出模块之间的依赖关系图，找出循环依赖。
3. 接口定义：为每个模块定义清晰的输入输出接口。
4. 边界验证：模拟模块替换场景，验证接口是否足够抽象。

下面这张图，是我常用的模块划分流程：

在实际项目中，我常用两种划分策略：

• 按硬件边界划分：每个外设一个模块，比如 UART 模块、I2C 模块、SPI 模块。适合驱动层。
• 按业务功能划分：每个业务场景一个模块，比如网络管理模块、电源管理模块、日志模块。适合应用层。

3.5 模块化设计的常见误区

误区	表现	后果
过度抽象	接口层数太多，调用链深	性能下降，调试困难
接口膨胀	一个接口包含太多方法	模块耦合度高，改动影响大
循环依赖	模块 A 依赖 B，B 又依赖 A	编译死循环，无法独立测试
共享全局变量	模块之间通过全局变量通信	状态不可控，并发问题多

嗯，这里要注意：模块化不是一蹴而就的。我习惯在项目初期先做一个“粗糙”的模块划分，然后在迭代中逐步优化。别想着一步到位，那反而容易陷入过度设计的泥潭。