📚 课程目录第2章中间件层设计原则

2. 中间件层设计原则：接口隔离、依赖倒置与模块解耦

中间件层，说白了就是连接底层硬件驱动和上层应用的那座桥。桥要是设计得不好，两边都跑不动。我这些年看过太多项目，中间件层写得像一团乱麻，改一个传感器驱动，结果三个任务都崩了。嗯，今天我们就聊聊怎么把这座桥搭稳。

2.1 接口隔离原则：别让调用者知道太多

接口隔离原则（ISP）的核心就一句话：客户端不应该依赖它不需要的接口。你想想看，一个温度传感器模块，上层应用只想读温度值，你却给它暴露了I²C初始化、寄存器配置、DMA通道设置……这不合理。

核心思想： 胖接口拆成多个小接口，每个接口只做一件事。

我在项目中遇到过这样一个案例：一个智能家居网关，所有传感器共用一个数据采集接口。结果Wi-Fi模块的开发者不得不实现一个“读取温度”的方法，而它根本不需要。后来我把接口拆成ITemperatureSensor、IHumiditySensor、IMotionSensor，每个接口只暴露自己需要的方法。代码瞬间清爽了。

违反ISP的写法	符合ISP的写法
一个ISensor接口包含所有传感器方法	拆分为ITemperatureSensor、IHumiditySensor等
调用者需要实现空方法或返回错误码	调用者只实现自己需要的接口
接口变更影响所有实现者	接口变更只影响相关实现者

// 违反ISP：一个接口包含太多方法
typedef struct {
    int32_t (*init)(void);
    int32_t (*read_temperature)(float *temp);
    int32_t (*read_humidity)(float *humi);
    int32_t (*read_pressure)(float *pres);
    int32_t (*config_i2c)(uint32_t freq);
} ISensor;

// 符合ISP：拆分为独立接口
typedef struct {
    int32_t (*init)(void);
    int32_t (*read)(float *value);
} ITemperatureSensor;

typedef struct {
    int32_t (*init)(void);
    int32_t (*read)(float *value);
} IHumiditySensor;

我的习惯： 接口文件按功能模块命名，比如 temp_sensor_if.h、humidity_sensor_if.h。头文件里只放结构体声明和函数指针，不放实现。

2.2 依赖倒置原则：高层模块不依赖底层细节

依赖倒置原则（DIP）听起来玄乎，其实道理很简单：高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

为什么会这样？我举个例子。你写了一个数据采集任务，它直接调用了某个具体传感器的驱动函数。三个月后，老板说换传感器型号了。你怎么办？改任务代码？那任务里还有日志、报警、存储的逻辑，改一处可能牵出三处bug。

我曾经踩过的坑： 一个温控系统，业务逻辑层直接调用了DS18B20的驱动API。后来换成NTC热敏电阻，业务逻辑层几乎重写。如果当时依赖的是抽象接口，只需要换一个驱动适配层就行。

正确的做法是：业务逻辑层只依赖接口，底层驱动去实现这些接口。这样，换硬件就像换灯泡一样简单。

// 违反DIP：业务层直接依赖具体驱动
void temperature_task(void *param) {
    float temp;
    ds18b20_read(&temp);  // 直接调用具体驱动
    process_temperature(temp);
}

// 符合DIP：业务层依赖抽象接口
void temperature_task(ITemperatureSensor *sensor, void *param) {
    float temp;
    sensor->read(&temp);  // 通过接口调用
    process_temperature(temp);
}

2.3 模块解耦：让每个模块都能独立演进

模块解耦，说白了就是让模块之间的依赖关系降到最低。你想想看，一个嵌入式系统里，任务调度、数据采集、日志记录、通信协议……这些模块如果耦合在一起，改一个就得重新编译整个工程。

我个人习惯用事件驱动的方式来解耦。模块之间不直接调用，而是通过消息队列或事件总线通信。这样，每个模块只需要关心自己收到什么事件、发出什么事件，不需要知道事件是谁发的、谁在处理。

  解耦的三个层次：
  编译时解耦： 使用接口头文件，不包含具体实现头文件
链接时解耦： 使用函数指针或虚函数表，运行时绑定
运行时解耦： 使用消息队列或事件总线，异步通信

耦合方式	依赖关系	修改影响范围	推荐场景
直接函数调用	强耦合	全局	同一模块内部
接口+函数指针	弱耦合	局部	模块间调用
事件/消息队列	解耦	无直接影响	跨任务通信

// 事件驱动解耦示例
typedef enum {
    EVT_TEMPERATURE_READY,
    EVT_ALARM_TRIGGERED,
    EVT_COMMAND_RECEIVED
} EventId_t;

typedef struct {
    EventId_t id;
    uint32_t data_len;
    void *data;
} Event_t;

// 模块A：发布事件
void temperature_module_task(void *param) {
    float temp;
    sensor_read(&temp);
    Event_t evt = {EVT_TEMPERATURE_READY, sizeof(temp), &temp};
    event_bus_publish(&evt);
}

// 模块B：订阅事件
void logging_module_init(void) {
    event_bus_subscribe(EVT_TEMPERATURE_READY, log_temperature);
}

2.4 标准化接口定义：让团队协作不再痛苦

标准化接口定义，这件事看起来简单，做起来最难。我见过一个团队，三个人写了三种风格的接口：有人用int32_t返回错误码，有人用bool，还有人直接返回void然后靠全局变量传状态。嗯，这种项目维护起来，谁碰谁头疼。

我个人建议，团队里必须有一个接口定义规范，白纸黑字写清楚：

返回值规范： 统一使用int32_t，0表示成功，负数表示错误码
命名规范： 模块名_动作_对象，比如temp_sensor_read
参数规范： 输入参数用const修饰，输出参数用指针
头文件规范： 每个接口单独一个头文件，使用#ifndef防止重复包含

我的经验： 接口定义文件里只放结构体、枚举和函数指针类型定义。不要放任何全局变量或静态函数。这样，其他模块只需要包含头文件，不需要关心实现细节。

// 标准化接口定义示例
#ifndef __TEMP_SENSOR_IF_H__
#define __TEMP_SENSOR_IF_H__

#include <stdint.h>

// 错误码定义
#define TEMP_SENSOR_OK      0
#define TEMP_SENSOR_ERR_INIT    -1
#define TEMP_SENSOR_ERR_READ    -2
#define TEMP_SENSOR_ERR_TIMEOUT -3

// 接口结构体
typedef struct {
    int32_t (*init)(void);
    int32_t (*read)(float *temperature);
    int32_t (*deinit)(void);
} ITempSensor;

#endif /* __TEMP_SENSOR_IF_H__ */

2.5 知识体系总览

下面这张图，把中间件层设计的四个原则串起来了。你可以把它当作设计时的检查清单。

这四个原则，说起来容易做起来难。我建议你在下一个项目里，先挑一个模块试试。比如从传感器驱动开始，按照接口隔离和依赖倒置的原则重新设计。你会发现，改完之后，代码的可测试性和可维护性都上了一个台阶。

注意： 不要为了设计而设计。如果你的系统只有两个模块，而且永远不会变，那过度设计就是浪费。原则是工具，不是教条。用在哪里、用多少，你自己判断。