第1章 依赖注入核心概念与BLE模块的契合点
蓝牙低功耗（BLE）模块在嵌入式系统中往往承担复杂的协议栈交互、硬件抽象和业务逻辑耦合。传统编码方式下，BLE的初始化、连接管理、GATT服务注册等代码直接写死在业务类中，造成强耦合、难测试、不可复用的痛点。依赖注入（Dependency Injection，DI）通过将依赖的创建和绑定从客户端移交给外部注入器，正好切中BLE模块的解耦需求。
1.1 为什么BLE模块需要依赖注入
- 硬件抽象分离：BLE底层可能使用不同芯片（Nordic、TI、Dialog等），DI允许将HCI驱动、射频配置作为接口注入，实现平台无关。
- 状态机与回调解耦：BLE连接状态机、MTU协商、配对逻辑通常由回调驱动。DI可以将回调处理器作为依赖注入，便于单元测试时替换为模拟回调。
- 可替换的协议栈：不同BLE协议栈API差异大（Zephyr、ESP-IDF、mbed OS）。通过DI注入协议栈适配器，业务代码无需修改即可切换。
- 数据流控制：BLE数据收发可能经过编码/解码、加密/解密、分包/重组。DI允许将数据处理器以管道形式注入，灵活组合。
关键洞察：BLE模块的依赖注入边界正是接口层——所有需替换的职责都抽象为接口，注入器负责在边界处组装具体实现。
1.2 DI基本三角
依赖注入围绕三个核心角色构建，其关系构成经典的DI三角：
| 角色 | 职责 | BLE示例 |
|---|---|---|
| 接口（Interface） | 定义依赖的抽象契约，不涉及实现细节 | IBleDriver：提供Send、Receive、Connect等纯虚方法 |
| 客户端（Client） | 使用接口完成业务逻辑，不负责创建依赖 | BleServiceManager：通过IBleDriver发送数据，不关心底层是串口还是USB |
| 注入器（Injector） | 组装并绑定具体实现到客户端 | 系统启动时，将NordicBleDriver实例通过构造函数或setter注入到BleServiceManager |
1.3 边界在DI中的角色
在嵌入式系统中，边界指模块间依赖关系的切断点。DI将边界显式化为接口定义的位置：
- 编译时边界：接口头文件（如
IBleDriver.h）隔离了客户端的编译依赖，只有接口变更才会触发全量重编译。 - 运行时边界：注入器根据配置或硬件类型选择合适的实现，实现“一次编译、多处运行”。
- 测试边界：注入Mock实现替代真实硬件，可在开发者工位运行单元测试，无需连接BLE硬件。
边界失效典型反例：如果客户端直接调用
NordicBleDriver::Init()，则依赖边界消失，替换芯片时需修改大量业务代码。
1.4 DI三角与BLE模块的映射图
下图展示了DI三角如何嵌入BLE系统的分层结构中，箭头的方向代表依赖关系（客户端依赖接口，不依赖实现）。
1.5 使用DI vs 不使用DI的BLE模块对比
| 维度 | 传统强耦合方式 | 依赖注入方式 |
|---|---|---|
| 硬件替换 | 需修改业务代码中的Init()、Send()调用 |
只需更换注入的实现，业务代码零改动 |
| 单元测试 | 必须连接真实BLE外设，测试环境复杂 | 注入MockBleDriver，纯软件测试 |
| 编译耦合 | 头文件级耦合，修改驱动需重编译所有引用 | 仅接口头文件耦合，实现变更不影响客户端 |
| 代码可读性 | 业务逻辑与硬件初始化混杂 | 职责清晰，业务逻辑专注于协议 |
1.6 落地第一步：识别BLE模块的DI边界
在进入具体实现前，可以先通过接口识别工具发现边界：
// 典型的BLE业务接口（伪代码）
struct IBleDriver {
virtual bool Init(const BleConfig& cfg) = 0;
virtual void Send(uint8_t* data, uint16_t len) = 0;
virtual void RegisterCallback(IBleCallback* cb) = 0;
virtual ~IBleDriver() = default;
};该接口就是DI边界。任何遵循该接口的实现（Nordic、TI、ESP32等）都可以通过注入器无缝衔接。
常见误区：初学者常将DI边界放在“类”而非“接口”上，导致注入时需要依赖具体类类型，实际上退化为工厂模式。真正的DI边界必须是一份纯接口抽象。
1.7 本章验收标准
- 能用自己的语言解释“为什么BLE模块需要依赖注入”。
- 画出DI基本三角，并指出每个角色在BLE系统中的对应物。
- 识别出至少2个BLE模块中的DI边界（如驱动接口、回调接口、数据管道接口）。
- 区分“依赖注入”与“服务定位器”或“工厂模式”的边界差异。