📚 课程目录第3章依赖倒置原则（DIP）在嵌入式中的落地

3. 依赖倒置原则（DIP）在嵌入式中的落地：从“我调用你”到“你实现我”

依赖倒置原则，英文叫 Dependency Inversion Principle，简称 DIP。很多同学一听这名字就觉得抽象，其实说白了就两句话：

高层模块不应该依赖低层模块，两者都应该依赖抽象。
抽象不应该依赖细节，细节应该依赖抽象。

在嵌入式里，这个原则的落地，就是一次思维上的翻转——从“我调用你”变成“你实现我”。

3.1 为什么嵌入式里更需要 DIP？

我刚开始做嵌入式那几年，写代码的习惯很直接：要操作一个传感器，就直接在业务逻辑里调用传感器的驱动函数。比如读温度，我就在主循环里写 temp = read_temperature_sensor()。看起来没毛病，对吧？

但问题很快就来了。项目中期，硬件工程师说：“这个传感器换型号了，接口不一样。” 我一看代码，好家伙，业务逻辑里到处都是 read_temperature_sensor() 的调用，改起来简直是噩梦。

为什么会这样？因为我的高层业务逻辑直接依赖了低层的传感器驱动。这种依赖关系是“硬编码”的，一旦低层变化，高层就得跟着改。

核心痛点： 嵌入式系统中，硬件变化是常态。MCU 换型号、外设换芯片、通信协议升级……如果代码是“我调用你”的直连模式，每一次硬件变动都意味着大面积重构。

3.2 从“我调用你”到“你实现我”

DIP 的落地，就是引入一个“抽象层”。这个抽象层定义好“我要什么”，而具体的实现由低层模块去完成。

我习惯把这个抽象层叫做“接口”或者“契约”。高层模块只跟这个契约打交道，低层模块去实现这个契约。这样一来，高层不再依赖低层，而是双方都依赖抽象。

举个例子，还是读温度：

传统方式（我调用你）： 业务逻辑 → 直接调用 sensor_driver_read()
DIP 方式（你实现我）： 业务逻辑 → 依赖 ITemperatureSensor 接口 → 具体驱动实现该接口

你看，业务逻辑不再关心底层是 I2C 还是 SPI，它只认接口。换传感器？只要新驱动实现同一个接口，业务代码一行都不用改。

我的经验： 在项目初期就定义好这些接口，哪怕一开始只有一个实现。这就像给代码留了一个“扩展口”，后面换硬件时你会感谢自己的。

3.3 嵌入式 DIP 的典型落地方式

在嵌入式 C 语言里，没有面向对象的“接口”关键字，但我们有几种成熟的实现方式：

实现方式	适用场景	优点	缺点
函数指针结构体	驱动层、协议栈	灵活，运行时可以切换实现	增加间接调用开销
弱符号 + 强符号覆盖	MCU 底层 HAL 库	编译时绑定，零运行时开销	调试时容易混淆符号来源
条件编译 + 抽象头文件	单板、单芯片项目	简单直接，无额外开销	扩展性差，换硬件需重新编译
回调函数注册	事件驱动、中断处理	解耦彻底，适合异步场景	回调层级深时难以追踪

我个人最常用的是函数指针结构体的方式。它既保留了 C 语言的轻量特性，又实现了面向对象的多态效果。

3.4 代码示例：用函数指针结构体实现 DIP

假设我们有一个温度采集模块，需要支持两种传感器：DS18B20 和 SHT30。

第一步：定义抽象接口

// temperature_sensor_if.h
typedef struct {
    int8_t (*init)(void);
    int8_t (*read_temperature)(float *temp);
    int8_t (*deinit)(void);
} temperature_sensor_t;

第二步：高层业务模块只依赖接口

// temperature_monitor.c
#include "temperature_sensor_if.h"

static const temperature_sensor_t *sensor;

void temperature_monitor_init(const temperature_sensor_t *s) {
    sensor = s;
    if (sensor->init() != 0) {
        // 错误处理
    }
}

float temperature_monitor_get_current(void) {
    float temp = 0.0f;
    if (sensor->read_temperature(&temp) != 0) {
        return -273.15f; // 错误返回值
    }
    return temp;
}

第三步：低层驱动实现接口

// ds18b20_driver.c
#include "temperature_sensor_if.h"

static int8_t ds18b20_init(void) {
    // 初始化 DS18B20 的 GPIO 和时序
    return 0;
}

static int8_t ds18b20_read(float *temp) {
    // 读取 DS18B20 温度值
    *temp = 25.3f;
    return 0;
}

const temperature_sensor_t ds18b20_sensor = {
    .init = ds18b20_init,
    .read_temperature = ds18b20_read,
    .deinit = NULL
};

第四步：在 main 中绑定

// main.c
#include "temperature_monitor.h"
#include "ds18b20_driver.h"

int main(void) {
    temperature_monitor_init(&ds18b20_sensor);
    while (1) {
        float temp = temperature_monitor_get_current();
        // 处理温度
    }
}

你看，temperature_monitor 完全不知道底层是 DS18B20 还是 SHT30。它只认 temperature_sensor_t 这个接口。换传感器？只需要在 main.c 里改一行初始化代码。

注意： 函数指针结构体会带来额外的间接调用开销。在极端实时性要求（如中断服务函数内）的场景下，需要评估是否可接受。我一般建议在非中断路径上使用，或者用 inline 函数配合编译优化来缓解。

3.5 DIP 在嵌入式架构中的位置

下面这张图展示了 DIP 在典型嵌入式分层架构中的角色：

3.6 避坑指南：我曾经踩过的坑

DIP 虽好，但落地时也有几个容易翻车的地方。我把自己踩过的坑分享给你：

过度抽象： 我曾经在一个只有两个传感器的项目里，设计了五层抽象接口。结果代码量翻倍，可读性下降，调试时跳来跳去。记住，抽象是为变化服务的，不要为抽象而抽象。
接口粒度过细： 每个函数都定义一个接口，导致接口数量爆炸。我建议按“设备功能”来划分，比如一个温度传感器接口包含 init、read、deinit 就够了。
忽略实时性： 函数指针间接调用在 Cortex-M4 上大约多花 3-5 个时钟周期。在 1MHz 的中断里，这个开销可能不可接受。我一般会在中断路径上用直接调用，在任务路径上用 DIP。
接口不稳定： 接口一旦定义好，就不要轻易改。否则所有实现都得跟着改，那就失去了 DIP 的意义。我习惯在项目初期花时间把接口设计稳，后面尽量只增不减。

我的建议： 从项目一开始就引入 DIP 思维，哪怕只有一个实现。这就像给代码预留了一个“扩展槽”，后面换硬件、加功能时，你会发现自己省了很多事。

3.7 小结

依赖倒置原则，说白了就是让高层模块“依赖抽象，而不是依赖具体”。在嵌入式里，这个原则的落地方式有很多，函数指针结构体是我最推荐的一种。

记住：从“我调用你”到“你实现我”，这个思维翻转，是嵌入式架构从“能用”走向“好改”的关键一步。