3、核心概念：模块化、分层、接口、耦合与内聚——嵌入式架构的五大基石
做嵌入式架构设计，说白了就是在跟复杂度打交道。我见过太多项目，一开始代码跑得挺欢，三个月后改一个 bug 要花两天，半年后新功能根本不敢加。为什么？因为架构没立住。
今天聊的这五个概念——模块化、分层、接口、耦合、内聚——就是架构的承重墙。你把这五样搞明白了，写出来的代码十年后还能改。
3.1 模块化：把大问题切成小问题
模块化不是什么高深理论。你想想看，一个 10 万行的工程，如果全塞在一个文件里，谁敢动？
模块化的本质就一句话：高内聚、低耦合的单元划分。每个模块负责一块清晰的职责，对外暴露必要的接口，内部实现细节藏起来。
模块划分的黄金法则：
- 单一职责：一个模块只做一件事，并且把它做好
- 接口最小化：暴露出去的东西越少，未来改动的自由度越大
- 可替换性：换掉一个模块的实现，不影响其他模块
我在项目中遇到过最典型的反面教材：一个“驱动模块”里既管 I2C 读写，又做数据校验，还顺带处理日志。后来要换 I2C 芯片，结果日志逻辑也跟着崩了。嗯，这就是模块化没做好。
3.2 分层：让代码有秩序
分层架构，说白了就是给代码排座次。谁在上层，谁在下层，谁可以调用谁，必须清清楚楚。
嵌入式系统最常见的分层模型是这样的：
| 层次 | 职责 | 典型内容 |
|---|---|---|
| 应用层 | 业务逻辑、状态机、用户交互 | 任务调度、协议解析、UI 逻辑 |
| 中间件层 | 抽象服务、协议栈、算法库 | 文件系统、TCP/IP 栈、加密库 |
| 硬件抽象层 (HAL) | 屏蔽硬件差异，提供统一接口 | GPIO、UART、SPI、I2C 抽象 |
| 驱动层 | 直接操作寄存器、外设控制 | 芯片手册实现的底层代码 |
这里有个关键原则：上层可以调用下层，下层绝不能反向依赖上层。我曾经在一个项目里看到驱动层直接调用了应用层的回调函数——结果换了一个 RTOS 之后，整个驱动层都得重写。教训深刻。
我的个人习惯：在 HAL 层定义接口时，用结构体函数指针表。这样换芯片时只需要重新实现这个表，上层代码一行都不用改。
3.3 接口：模块之间的契约
接口就是模块之间的“合同”。合同写得越清楚，双方扯皮越少。
好的接口设计有几个特征：
- 参数简单：能用基本类型就别传结构体，能传一个参数就别传三个
- 行为可预期：同样的输入，永远产生同样的输出（或者明确的错误码）
- 错误处理明确：返回 -1 还是 NULL？用 errno 还是异常？提前约定好
// 好的接口设计示例
// 清晰、简单、可预期
int hal_i2c_write(uint8_t dev_addr, uint8_t reg_addr,
const uint8_t *data, uint16_t len);
// 返回值：成功返回 0，失败返回负错误码
// 错误码定义：
// -EINVAL: 参数无效
// -ETIMEDOUT: 总线超时
// -EIO: 硬件错误避坑指南：我曾经见过一个接口函数有 8 个参数，其中 3 个是输出参数。调用者每次都要小心翼翼地对齐顺序，少传一个就出野指针。后来我重构时强制要求：接口参数不超过 4 个，超过就用结构体打包。
3.4 耦合与内聚：架构质量的度量尺
这两个概念是成对出现的。耦合衡量模块之间的依赖程度，内聚衡量模块内部的关联程度。
| 类型 | 低（好） | 高（坏） |
|---|---|---|
| 耦合 | 数据耦合、消息耦合 | 内容耦合、公共耦合 |
| 内聚 | 功能内聚、顺序内聚 | 偶然内聚、逻辑内聚 |
你想想看，如果模块 A 直接读写模块 B 的内部全局变量——这就是内容耦合，最糟糕的那种。改 B 的时候必须改 A，改 A 的时候又可能影响 B。这种代码我称之为“蜘蛛网代码”，牵一发动全身。
反过来，内聚度高的模块，所有代码都在为同一个目标服务。比如一个“CRC 计算模块”，里面全是 CRC 相关的函数，没有别的。这就是功能内聚，最理想的状态。
我的经验法则：
- 模块之间的调用关系画成图，如果出现循环依赖，说明耦合有问题
- 一个模块的代码如果超过 2000 行，大概率内聚度已经下降了
- 接口参数超过 4 个，或者返回值类型不统一，说明接口设计需要重新审视
3.5 五大基石的关系图
下面这张图展示了这五个概念如何共同支撑起一个健壮的嵌入式架构：
3.6 实战中的取舍
理论说完了，聊聊现实。嵌入式系统资源有限，有时候你没法做到完美。
比如在 Cortex-M0 这种只有几 KB RAM 的芯片上，你非要搞七层分层架构，那纯粹是给自己找麻烦。这时候我的做法是：优先保证模块化和接口清晰，分层可以适当扁平化。
再比如，有些模块之间确实需要频繁交换数据。强行解耦只会让代码变得又臭又长。这时候我选择接受合理的数据耦合，但坚决杜绝内容耦合（直接访问对方内部变量）。
我的决策清单：
- 先画模块依赖图，找出循环依赖——必须拆
- 检查每个模块的接口数量——超过 5 个考虑合并或拆分
- 评估模块的内聚度——如果模块里有“杂项”函数，立刻重构
- 根据硬件资源决定分层深度——资源紧张时最多 3 层
记住一句话：架构设计不是追求完美，而是在约束条件下找到最优解。这五个基石就是你的工具箱，用好了，十年后的工程师会感谢你。