耦合与内聚的度量：耦合类型、内聚级别与现有代码评估

在嵌入式软件架构设计中，耦合与内聚是衡量模块化质量的两个核心维度。耦合描述模块之间的相互依赖程度，内聚描述模块内部各元素结合的紧密程度。理想架构追求“高内聚、低耦合”，但工程实践中需要可量化的判断标准，而非仅凭直觉。本章将系统梳理耦合的四种类型（数据、控制、外部、公共）与内聚的三个关键级别（功能、顺序、通信），并给出评估现有代码的具体操作路径。

核心原理：耦合与内聚的度量维度

耦合与内聚并非抽象概念，而是可以通过代码结构特征进行识别的工程属性。耦合的强度取决于模块之间连接的复杂程度：数据耦合最弱，仅通过函数参数传递基础类型数据；控制耦合意味着模块间传递控制标志或命令字，接收方需要理解发送方的业务逻辑；外部耦合表现为对共享外部资源（如通信协议、文件格式、硬件寄存器）的依赖；公共耦合则是最强耦合，多个模块直接读写同一全局变量或公共内存区。内聚级别则反映模块内部元素的关联性质：功能内聚中所有代码共同完成一个明确任务；顺序内聚中元素按数据流顺序排列，前一个的输出是后一个的输入；通信内聚中元素操作同一数据集但各自独立；而逻辑、时间或偶然内聚则属于低质量设计，应通过重构消除。

判断方法：耦合类型识别与内聚级别判定

评估现有代码时，建议按以下流程操作：

1. 绘制模块依赖图：列出所有源文件或函数模块，标注它们之间的调用关系、参数传递、全局变量访问和外部资源使用。
2. 分类耦合类型：对每条依赖边，判断属于数据、控制、外部还是公共耦合。重点关注是否有模块直接访问其他模块的全局变量，是否有模块通过参数传递命令码或状态标志。
3. 分析模块内部结构：对每个模块，检查内部函数和语句之间的关系。若所有代码围绕单一功能展开，则为功能内聚；若代码按固定顺序处理数据流，则为顺序内聚；若多个函数操作同一缓冲区但功能各异，则为通信内聚。
4. 量化评估：统计各耦合类型占比和各内聚级别占比，形成架构健康度报告。

案例拆解：电机控制模块的耦合与内聚分析

某工业驱动器固件中，motor_ctrl.c 模块负责电机启停、速度调节和故障处理。初始代码中，模块直接访问全局变量 g_motor_speed 和 g_fault_flag，同时通过 set_operation_mode() 函数传递模式枚举值，内部用 switch 分支执行不同算法。评估发现：g_motor_speed 被 comm_handler.c（通信模块）和 safety_monitor.c（安全监控）同时读写，属于公共耦合；set_operation_mode() 的控制参数导致调用方需要了解内部实现，属于控制耦合。模块内部，速度计算、故障检测、通信解析三个功能混在一起，属于逻辑内聚。

重构方案：将速度数据封装为独立模块 speed_manager.c，提供 get_speed() 和 set_speed() 接口，消除公共耦合；将操作模式改为函数指针表，消除控制耦合；将故障检测拆分为独立模块，使 motor_ctrl.c 聚焦于电机控制主逻辑，达到功能内聚。重构后，模块间仅通过数据耦合交互，测试时可用桩模块替换依赖，单元测试覆盖率从45%提升至82%。

实战场景：嵌入式代码评估操作清单

在真实项目中，建议按以下清单执行评估：

• 静态扫描：使用 grep 或静态分析工具查找 extern 全局变量声明，统计每个全局变量的访问点数量。访问点超过3个的变量应视为公共耦合风险。
• 函数签名审查：检查函数参数中是否有 uint8_t mode、bool enable 等控制型参数。若函数内部根据参数执行不同算法，则存在控制耦合。
• 模块内聚度测试：尝试用一句话描述每个模块的职责。如果无法用一句话说清，或需要列举多个功能，则内聚度不足。
• 依赖方向检查：绘制模块依赖图，检查是否存在循环依赖（A调用B，B又调用A）。循环依赖通常伴随公共耦合。

// 公共耦合示例：多个模块直接访问全局变量
// motor_ctrl.c
extern uint32_t g_motor_speed;
void motor_update(void) {
    g_motor_speed = calculate_speed();
}

// comm_handler.c
extern uint32_t g_motor_speed;
void comm_send_speed(void) {
    send_packet(g_motor_speed);
}

// 重构后：通过接口访问
// speed_manager.h
uint32_t speed_get(void);
void speed_set(uint32_t speed);

总结复盘：度量驱动的架构演进

耦合与内聚的度量不是一次性的评审活动，而应融入日常开发流程。建议在代码评审中加入耦合/内聚检查项，在持续集成中运行静态分析脚本，定期输出架构健康报告。当发现公共耦合或低内聚模块时，优先重构高风险模块，因为这类问题会随着系统规模扩大而指数级恶化。值得注意的是，嵌入式系统中外部耦合（如硬件寄存器操作）无法完全消除，但可以通过硬件抽象层（HAL）将其隔离在单一模块内，避免扩散到业务逻辑层。最终目标是让每个模块都能独立编译、独立测试、独立替换，这才是低耦合高内聚架构的实际价值。