📚 课程目录第3章耦合度控制基础

3. 耦合度控制基础：耦合的定义与危害

模块之间怎么打交道，这事比你想的重要得多。我见过太多系统，功能全对，但改一行代码要牵动十几个文件——这就是耦合失控的典型症状。

耦合，说白了就是模块之间的依赖程度。依赖越强，牵一发动全身的风险就越大。今天咱们把这六种耦合类型掰开揉碎讲清楚。

3.1 耦合的定义与核心危害

耦合度衡量的是一个模块对另一个模块的了解程度。你了解得越深，改动时就越容易伤到对方。

核心危害就三点：

修改扩散：改A模块，B、C、D都得跟着改
复用困难：想拿走一个模块，得连带搬走它依赖的一堆东西
测试复杂：测一个功能，得把整个系统跑起来

我早期做车载仪表盘项目时，就吃过这个亏。一个显示模块直接读了底层传感器的寄存器地址，结果传感器换了型号，显示模块、数据处理模块、报警模块全得重写。嗯，那次教训挺深刻的。

3.2 六种耦合类型详解

耦合从低到高分六个等级。咱们从最理想的开始，一路看到最糟糕的。

耦合类型	依赖方式	修改影响范围	推荐度
数据耦合	只传递基本类型参数	仅被调函数	✅ 推荐
标记耦合	传递结构体/对象	结构体成员变更时扩散	⚠️ 谨慎
控制耦合	传递控制标志/命令码	控制逻辑变更时扩散	⚠️ 尽量避免
外部耦合	依赖外部协议/文件格式	外部规范变更时全链修改	❌ 需隔离
公共耦合	共享全局变量/公共内存	任何写操作都可能影响全局	❌ 严格限制
内容耦合	直接访问对方内部数据/代码	内部实现变更即破坏	🚫 禁止

3.2.1 数据耦合（Data Coupling）

这是最干净的耦合方式。模块之间只通过函数参数传递基本类型数据，比如 int、float、char。调用者不关心被调函数内部怎么实现，被调函数也不依赖调用者的任何上下文。

// 数据耦合：只传递基本类型
int calculate_battery_level(int voltage_mv, int capacity_mah) {
    return (voltage_mv * 100) / capacity_mah;
}

// 调用方完全不需要知道内部实现
int level = calculate_battery_level(3700, 3000);

我个人习惯，能写成数据耦合就绝不升级到更高级别。它改起来最安全，测起来也最简单。

3.2.2 标记耦合（Stamp Coupling）

传递整个结构体或对象，但函数只用其中一部分字段。问题就出在这里——结构体里多一个字段，所有用到这个结构体的函数都得重新编译。

// 标记耦合：传递整个结构体，但只用其中两个字段
typedef struct {
    int voltage_mv;
    int capacity_mah;
    int temperature_c;   // 这个字段 calculate 根本不用
    int cycle_count;     // 这个字段也不用
} BatteryInfo;

int calculate_battery_level(BatteryInfo *info) {
    // 只用到了 voltage_mv 和 capacity_mah
    return (info->voltage_mv * 100) / info->capacity_mah;
}

避坑指南：我曾经在一个BMS项目中，把传感器数据打包成一个巨型结构体到处传。后来温度传感器从DS18B20换成NTC，结构体里字段类型变了，结果12个文件需要重新编译测试。如果当时只传需要的参数，改一个文件就够了。

3.2.3 控制耦合（Control Coupling）

调用方通过参数告诉被调函数「该做什么」。比如传一个命令码或枚举值，函数内部根据这个值走不同分支。

// 控制耦合：用参数控制函数行为
void process_command(int cmd) {
    switch(cmd) {
        case 0x01: start_motor(); break;
        case 0x02: stop_motor(); break;
        case 0x03: reset_system(); break;
        // 每加一个命令，这里就得加一个case
    }
}

为什么说它不好？因为调用方必须知道被调函数支持哪些命令码。命令码一变，两边都得改。更好的做法是把不同命令拆成独立函数。

3.2.4 外部耦合（External Coupling）

模块依赖外部环境，比如文件格式、通信协议、硬件寄存器地址。外部规范一变，所有依赖它的模块都得跟着改。

典型场景：

多个模块直接解析同一个CAN报文ID
多个模块直接读写同一个文件格式
多个模块直接操作硬件寄存器地址

解决办法是加一层抽象。比如把所有CAN报文解析集中到一个模块，其他模块通过函数接口获取数据。这样协议变了，只改一个模块。

3.2.5 公共耦合（Common Coupling）

多个模块共享同一个全局变量或公共内存区。这是嵌入式系统里最常见的耦合陷阱，尤其是在中断服务和主循环之间。

// 公共耦合：全局变量被多处访问
int g_sensor_value = 0;

// 中断服务中写入
void ISR_Timer(void) {
    g_sensor_value = read_adc();
}

// 主循环中读取
void main_loop(void) {
    if(g_sensor_value > 100) {
        trigger_alarm();
    }
}

注意：公共耦合不仅带来修改风险，还引入并发问题。中断和主循环同时访问同一个全局变量，不加保护的话，读到半新不旧的数据是常有的事。我曾经排查过一个偶发性的误报警问题，查了两天才发现是全局变量在中断里被修改，主循环读到的是脏数据。

3.2.6 内容耦合（Content Coupling）

这是最糟糕的耦合。一个模块直接访问另一个模块的内部数据或代码。比如直接修改另一个模块的私有变量，或者跳转到另一个模块的内部标签。

// 内容耦合：直接访问另一个模块的内部数据
// module_a.c
static int internal_state = 0;

// module_b.c
extern int internal_state;  // 强行访问私有变量
internal_state = 0xFF;      // 直接修改，破坏封装

这种耦合在正规项目中应该零容忍。它让模块之间的边界完全消失，任何内部实现变更都会导致不可预知的崩溃。

3.3 耦合度控制实战原则

讲完理论，给几条我实际项目中一直用的原则：

接口越小越好：函数参数不超过3个，能用基本类型就别用结构体
单向依赖：模块A依赖模块B，但B不能反过来依赖A
全局变量要集中管理：用专门的模块封装所有全局状态，提供读写接口
外部依赖加隔离层：硬件、协议、文件格式的变化不要扩散到业务逻辑

个人经验：我每次评审代码时，会先看函数签名。如果看到参数里有结构体指针但函数只用其中两个字段，或者看到全局变量在三个以上文件中被修改，我就会标记为「需要重构」。这些地方往往是未来出问题的重灾区。

3.4 耦合度知识图谱

下面这张图把六种耦合类型按危害程度排列，并标注了核心特征和应对策略。

3.5 小结

耦合度控制是软件架构的基本功。记住一个原则：能低就别高，能小就别大。数据耦合是最安全的，内容耦合是绝对不能碰的。中间那四种，根据实际情况权衡，但心里要有根弦——耦合度越高，未来的维护成本就越高。

我每次做架构评审时，都会拿这张耦合度表对照一遍。发现标记耦合以上的依赖，就会问自己一句：「能不能再降一级？」很多时候，多花半小时设计接口，能省下后面几天的调试时间。