模块接口最小化原则：信息隐藏与接口暴露的平衡

做嵌入式系统重构这么多年，我见过太多“接口膨胀”的惨案。一个模块恨不得把所有内部变量都暴露出去，结果就是牵一发而动全身。今天咱们就聊聊怎么把握这个度——信息隐藏和接口暴露的平衡。

信息隐藏：不是藏着掖着，是保护

信息隐藏（Information Hiding）这个概念，说白了就是：模块内部怎么折腾，那是它自己的事，外部别管。我早期做的一个项目，一个驱动模块把寄存器地址直接暴露给了上层应用。后来芯片换型号，寄存器地址变了，结果上层代码改得那叫一个惨。

举个例子，一个温度传感器模块：

// 不好的设计：暴露了太多内部细节
typedef struct {
    uint8_t reg_addr;
    uint16_t calibration_factor;
    uint8_t i2c_bus;
} TempSensor_Handle;

int32_t TempSensor_ReadRaw(TempSensor_Handle* handle);
int32_t TempSensor_ApplyCalibration(int32_t raw_value, uint16_t factor);

// 好的设计：只暴露必要的接口
typedef void* TempSensor_Handle;  // 不透明指针

int32_t TempSensor_Init(TempSensor_Handle* handle, uint8_t sensor_id);
int32_t TempSensor_GetTemperature(TempSensor_Handle handle, float* temp);

你看，好的接口设计，外部根本不需要知道内部用了什么校准算法、I2C地址是多少。你想想看，如果以后要换算法，或者改通信方式，只要接口不变，上层代码一行都不用改。

接口暴露的“度”在哪里？

信息隐藏不是什么都不暴露。我总结了一个“三问法”：

1. 这个接口真的需要吗？——去掉它，功能还能不能完成？
2. 这个接口会被谁调用？——是内部模块还是外部系统？
3. 这个接口暴露了实现细节吗？——调用者需要知道内部结构才能用吗？

暴露级别	典型场景	风险
完全隐藏	内部数据结构、局部变量	无风险，推荐
受控暴露	初始化、配置、状态查询	低风险，需文档化
过度暴露	内部寄存器、中间计算结果	高风险，耦合度飙升

Liskov替换原则：接口的“契约精神”

Liskov替换原则（LSP）听起来高大上，其实核心就一句话：子类应该能替换父类，而且程序行为不变。在嵌入式C语言里，我们更多是通过函数指针和接口结构体来实现。

我曾经在一个项目中，设计了一个通用的传感器接口：

// 通用传感器接口
typedef struct {
    int32_t (*init)(void* self);
    int32_t (*read)(void* self, uint8_t* data, uint32_t len);
    int32_t (*deinit)(void* self);
} SensorInterface;

// 温度传感器实现
static int32_t temp_init(void* self) { /* ... */ }
static int32_t temp_read(void* self, uint8_t* data, uint32_t len) { /* ... */ }
static int32_t temp_deinit(void* self) { /* ... */ }

SensorInterface temp_sensor = {
    .init = temp_init,
    .read = temp_read,
    .deinit = temp_deinit
};

// 压力传感器实现
static int32_t pressure_init(void* self) { /* ... */ }
static int32_t pressure_read(void* self, uint8_t* data, uint32_t len) { /* ... */ }
static int32_t pressure_deinit(void* self) { /* ... */ }

SensorInterface pressure_sensor = {
    .init = pressure_init,
    .read = pressure_read,
    .deinit = pressure_deinit
};

这里的关键是：所有传感器实现都必须遵守同一个契约。init、read、deinit的语义必须一致。如果某个传感器的read函数返回的是华氏温度，而其他传感器返回摄氏温度，那就违反了LSP。

信息隐藏与LSP的协同

这两个原则其实是相辅相成的。信息隐藏让接口更小、更稳定；LSP让接口更一致、更可替换。结合起来，就是一套完整的接口设计方法论。

实战中的平衡艺术

理论说完了，咱们看看实际怎么操作。我一般遵循这几个步骤：

1. 先画模块边界——明确哪些是内部实现，哪些是对外接口
2. 定义接口契约——每个接口的输入、输出、行为、错误处理都要明确
3. 写测试用例——用测试来验证接口是否满足LSP
4. 持续重构——发现接口膨胀就及时收缩

嗯，这里要注意：信息隐藏不是让你把所有东西都藏起来。有些场景下，适当的暴露反而能提高灵活性。比如调试接口、性能统计接口，这些可以单独放在一个“调试头文件”里，生产代码不包含它就行。

最后说一句：接口设计没有银弹。每个项目都有自己的上下文，关键是要理解原则背后的思想，而不是死记硬背规则。你想想看，如果接口设计真的那么简单，我们这些做架构的还怎么混饭吃？