4. 模块化设计原则：驱动模块化的核心思想

各位同学，今天我们来聊聊驱动模块化的核心原则。说实话，我早年做嵌入式开发时，也踩过不少坑。那时候写驱动，恨不得把所有功能塞进一个文件里。结果呢？改一个传感器，整个系统都要重新编译。后来接触了PX4的源码，才真正理解了什么叫「优雅的设计」。

模块化设计，说白了就是让每个模块各司其职，互不干扰。我总结下来，核心原则就三条：高内聚低耦合、接口隔离、依赖注入。咱们一条一条拆开讲。

4.1 高内聚低耦合：让模块「各扫门前雪」

高内聚，指的是一个模块内部的功能要紧密相关。低耦合，就是模块之间的依赖要尽可能少。你想想看，如果每个模块都只做自己该做的事，那系统维护起来得多轻松？

我在PX4的驱动代码里，经常看到这样的设计。比如一个IMU驱动，它只负责读取传感器数据、做校准、输出姿态信息。它不会去管GPS数据怎么处理，也不会关心电机怎么控制。这就是高内聚的典型表现。

来看一段PX4中加速度计驱动的伪代码：

// 高内聚示例：加速度计驱动只做加速度计的事
class AccelerometerDriver {
public:
    bool init();           // 初始化硬件
    bool calibrate();      // 校准
    bool read(sensor_accel_s &data); // 读取数据
    bool set_rate(uint32_t rate);    // 设置采样率
private:
    int _fd;               // 文件描述符
    uint32_t _rate;        // 采样率
};

你看，这个类的方法全部围绕「加速度计」这个核心功能展开。没有多余的东西。这就是高内聚。

至于低耦合，PX4是怎么做的呢？它通过uORB消息总线来实现。驱动模块只管往总线上发消息，其他模块需要数据就从总线上订阅。驱动不需要知道谁在用它的数据，用数据的人也不需要关心驱动是怎么实现的。

4.2 接口隔离：别让模块「知道太多」

接口隔离原则，说白了就是：不要强迫模块依赖它不需要的接口。我见过不少代码，一个驱动类里塞了十几个方法，但实际使用者只需要其中两三个。这就造成了不必要的依赖。

PX4是怎么处理这个问题的？它把驱动接口拆得很细。比如，一个传感器驱动，可能只暴露init()、read()、ioctl()这几个核心方法。其他像校准、自检等功能，都通过独立的接口或配置参数来实现。

来看一个实际例子：

// 接口隔离：只暴露必要的接口
class SensorDriver {
public:
    virtual bool init() = 0;
    virtual bool read(void *data, size_t len) = 0;
    virtual int ioctl(unsigned long cmd, unsigned long arg) = 0;
    virtual ~SensorDriver() = default;
};

// 具体实现可以扩展，但接口保持精简
class BMP280Driver : public SensorDriver {
public:
    bool init() override;
    bool read(void *data, size_t len) override;
    int ioctl(unsigned long cmd, unsigned long arg) override;
private:
    // 内部实现细节不暴露
    bool _calibrate();
    bool _set_mode(uint8_t mode);
};

嗯，这里要注意：接口隔离不是说接口越少越好，而是说每个接口的职责要单一。我曾经见过一个驱动接口，叫doEverything()，里面包含了初始化、读取、校准、甚至日志输出。这种设计，说白了就是接口隔离的反面教材。

4.3 依赖注入：让模块「即插即用」

依赖注入，听起来高大上，其实核心思想很简单：模块需要的依赖，由外部提供，而不是自己创建。这样做的好处是，模块可以轻松替换依赖的实现，方便测试和扩展。

在PX4中，依赖注入最常见的体现就是设备注册机制。驱动不直接创建硬件对象，而是通过框架提供的注册接口，把设备挂到系统总线上。其他模块通过设备名或设备号来获取驱动实例。

来看一个简化版的依赖注入示例：

// 依赖注入：驱动不自己创建依赖，而是由外部注入
class SensorManager {
public:
    // 注入驱动实例
    void register_driver(const char *name, SensorDriver *driver) {
        _drivers[name] = driver;
    }

    // 获取驱动实例
    SensorDriver* get_driver(const char *name) {
        auto it = _drivers.find(name);
        return (it != _drivers.end()) ? it->second : nullptr;
    }

private:
    std::map<std::string, SensorDriver*> _drivers;
};

// 使用方式
SensorManager manager;
BMP280Driver bmp280;
manager.register_driver("bmp280", &bmp280);

// 其他模块通过管理器获取驱动，不直接依赖具体实现
auto driver = manager.get_driver("bmp280");
if (driver) {
    driver->read(data, sizeof(data));
}

你想想看，这样做有什么好处？如果我想把BMP280换成BME280，只需要注册一个新的驱动实例，其他代码完全不用改。这就是依赖注入的魅力。

4.4 知识体系总览

为了让你更直观地理解这三个原则的关系，我画了一张图：

这张图展示了三个原则如何协同工作。高内聚低耦合定义了模块的职责边界，接口隔离约束了模块对外暴露的内容，依赖注入则提供了灵活的组合方式。三者缺一不可。

4.5 总结

好了，这一章的内容就到这里。模块化设计不是一蹴而就的，需要在实践中不断打磨。我个人建议，写驱动时先问自己几个问题：

• 这个模块的职责是什么？有没有做不该做的事？
• 其他模块需要知道这个模块的哪些细节？能不能隐藏起来？
• 如果我想换一个实现，需要改多少代码？

想清楚这些问题，你的驱动设计就不会差到哪里去。下一章，我们会深入PX4的驱动框架，看看这些原则是如何落地到具体代码中的。

---