接口抽象基础：什么是接口？接口与实现的分离

好，我们正式开始第二讲。上一章聊了模块化设计的大框架，这一章咱们得把最核心的概念讲透——接口。

说实话，我见过太多工程师，写了五六年嵌入式代码，还是把接口当成「头文件里的一堆函数声明」。嗯，这不算错，但远远不够。接口的本质，其实是一种契约。

1. 接口的本质：契约与边界

你想想看，为什么我们盖房子要先画图纸？因为泥瓦工和水电工需要知道：插座留多高、水管走哪边。图纸就是他们之间的契约。

接口也一样。它约定了两件事：

• 调用方能做什么（函数名、参数、返回值）
• 实现方必须提供什么（行为、时序、约束）

我在项目中遇到过最典型的反面教材：一个同事把全局变量直接暴露给所有模块调用。结果呢？产品迭代到第三版，没人敢改那个变量，因为不知道会影响多少个地方。这就是没有接口边界的下场。

2. 接口与实现的分离：为什么这么重要？

说白了，分离就是为了换。换硬件、换算法、换协议，不用动上层逻辑。

我举个例子。你写了一个温湿度传感器驱动，上层应用要读温度和湿度。如果你这么写：

// 糟糕的做法：直接暴露硬件细节
float get_temperature_from_sht30(void);
float get_humidity_from_sht30(void);

哪天老板说「成本压不下来，换DHT11」。好，你所有调用这两个函数的地方都得改。这叫紧耦合。

如果换成接口抽象：

// 接口定义：只关心「能读温度和湿度」
typedef struct {
    float (*read_temperature)(void);
    float (*read_humidity)(void);
} sensor_ops_t;

上层只跟 sensor_ops_t 打交道。换传感器？重新实现这两个函数指针就行。上层代码一行不动。

3. C语言中实现接口抽象的三种方式

嵌入式开发主力语言还是C。C没有interface关键字，但我们可以用三种经典手法实现接口抽象。

方式	原理	适用场景	灵活性
函数指针结构体	把一组函数指针打包成结构体	驱动层、协议层	高（运行时多态）
弱符号 + 强符号覆盖	用 __attribute__((weak)) 定义默认实现	库函数、回调钩子	中（编译时绑定）
预处理器宏抽象	通过宏将接口映射到不同实现	跨平台、条件编译	低（编译时固定）

我个人最常用的是函数指针结构体。为什么？因为它最接近OOP里的接口概念，而且调试时能清楚看到当前绑定了哪个实现。

4. 实战案例：一个串口接口的抽象

光说不练假把式。我们来看一个串口驱动的接口抽象。

// uart_interface.h
#ifndef UART_INTERFACE_H
#define UART_INTERFACE_H

#include <stdint.h>

// 串口配置参数
typedef struct {
    uint32_t baudrate;
    uint8_t  data_bits;
    uint8_t  stop_bits;
    uint8_t  parity;   // 0: none, 1: odd, 2: even
} uart_config_t;

// 串口操作接口
typedef struct {
    int32_t (*init)(void *handle, uart_config_t *cfg);
    int32_t (*send)(void *handle, const uint8_t *data, uint32_t len);
    int32_t (*receive)(void *handle, uint8_t *buf, uint32_t len);
    void    (*deinit)(void *handle);
} uart_ops_t;

#endif

你看，这个接口文件里没有任何硬件寄存器、没有具体芯片型号。它只定义了：你要初始化、发数据、收数据、反初始化。至于底层是STM32的USART还是NXP的LPUART，接口不关心。

然后我们给STM32写一个实现：

// uart_stm32.c
#include "uart_interface.h"

static int32_t stm32_uart_init(void *handle, uart_config_t *cfg) {
    // 操作STM32的USART寄存器
    // 配置波特率、数据位、停止位...
    return 0;
}

static int32_t stm32_uart_send(void *handle, const uint8_t *data, uint32_t len) {
    // 发送数据
    return 0;
}

// ... 其他函数实现

// 暴露接口实例
const uart_ops_t uart_stm32_ops = {
    .init    = stm32_uart_init,
    .send    = stm32_uart_send,
    .receive = stm32_uart_receive,
    .deinit  = stm32_uart_deinit,
};

上层应用只需要：

// app.c
#include "uart_interface.h"

extern const uart_ops_t uart_stm32_ops;

void app_init(void) {
    void *uart_handle = (void *)USART1;
    uart_config_t cfg = {115200, 8, 1, 0};
    
    uart_stm32_ops.init(uart_handle, &cfg);
    uart_stm32_ops.send(uart_handle, "Hello", 5);
}

换平台？把 uart_stm32_ops 换成 uart_nxp_ops 就行。上层代码一个字都不用改。

5. 接口抽象的核心原则

总结几条我这些年摸爬滚打总结出来的原则：

1. 最小接口原则：只暴露必须的操作。多一个函数就多一份耦合。
2. 接口稳定原则：接口一旦发布，尽量不改。要加功能？加新接口，别改旧的。
3. 接口自文档化：好的接口，看函数名和参数就知道怎么用。注释是辅助，不是救命稻草。
4. 避免类型泄露：接口里不要出现具体硬件的寄存器地址、中断号。用 void* 做句柄。

6. 接口抽象的知识体系

下面这张图梳理了接口抽象的核心逻辑，我建议你保存下来，写代码前瞄一眼。

7. 接口抽象带来的直接好处

说了这么多理论，咱们看看实际收益：

• 可替换性：换硬件、换协议，改一行代码甚至不改。
• 可测试性：写个Mock实现，就能在PC上跑单元测试。我在项目中用这个办法，把硬件依赖全部打掉，测试覆盖率从15%提到80%。
• 并行开发：A组写接口定义，B组写上层逻辑，C组写底层驱动。接口定好了，三组同时开工。
• 代码审查：审查接口比审查实现快得多。接口清晰，实现一般不会乱到哪去。