4. 软件复用基础：模块化设计原则、接口抽象、依赖倒置原则在汽车软件中的应用

各位同学，今天我们来聊聊软件复用。说实话，这个话题在汽车行业里，我见过太多人把它想简单了。

很多人觉得复用就是「把代码拷过来改一改」。嗯，我年轻时也这么干过。结果呢？一个 bug 改了三个项目，每个项目都得重新测一遍。那叫一个酸爽。

真正的复用，靠的是设计。不是复制粘贴。

今天我就把三个最核心的复用基础讲透：模块化设计、接口抽象、依赖倒置。这三个东西，说白了就是一套「如何让代码不被焊死」的方法论。

4.1 模块化设计原则：别把鸡蛋放在一个篮子里

模块化，听起来简单吧？就是把功能拆开。但拆到什么程度？怎么拆？这里头有讲究。

我个人习惯用两个原则来判断：

  • 高内聚：一个模块只干一件事，而且干得漂亮
  • 低耦合：模块之间尽量少说话，说话也只通过接口

我在做 BMS（电池管理系统）项目时遇到过一个问题。有个同事把「电压采集」和「温度计算」写在了同一个模块里。看起来挺方便，对吧？结果后来换了新的温度传感器，算法全变了。改一个功能，得动整个模块。这就是内聚不够。

正确的做法是什么？

// 不好的做法：电压和温度混在一起
class BatteryMonitor {
    float readVoltage() { /* ... */ }
    float calcTemperature() { /* ... */ }
}

// 好的做法：各管各的
class VoltageSensor {
    float read() { /* ... */ }
}

class TemperatureSensor {
    float read() { /* ... */ }
}

核心要点：模块化不是「把代码分文件」，而是「把职责分清楚」。一个模块只对一件事负责。

4.2 接口抽象：说好规则，别管细节

接口抽象，说白了就是「我只管你要什么，不管你怎么做」。

你想想看，汽车上有多少种传感器？温度、压力、转速、位置...每种传感器都有不同的厂商、不同的协议。如果每个模块都直接调用传感器的具体 API，那代码就乱成一锅粥了。

我建议的做法是：先定义接口，再实现细节。

// 定义抽象接口
class ISensor {
public:
    virtual float read() = 0;
    virtual bool selfCheck() = 0;
};

// 具体实现
class TemperatureSensor : public ISensor {
    float read() override { /* I2C读取 */ }
    bool selfCheck() override { /* 自检逻辑 */ }
};

class PressureSensor : public ISensor {
    float read() override { /* SPI读取 */ }
    bool selfCheck() override { /* 自检逻辑 */ }
};

这样做的好处是什么？

  • 上层模块只依赖 ISensor，不依赖具体传感器
  • 换传感器时，只需要新增一个实现类，不用改上层逻辑
  • 测试时，可以 mock 一个假传感器，不用真硬件

我的经验：接口定义要「够用但不过度」。我曾经见过有人把接口拆得太细，一个传感器接口拆了七八个虚函数，结果每个实现类都得写一堆空函数。嗯，那叫过度设计。

4.3 依赖倒置原则：让高层模块说了算

依赖倒置原则（DIP），名字听着挺唬人。其实核心就一句话：高层模块不应该依赖低层模块，两者都应该依赖抽象。

我举个例子你就明白了。

假设你有一个「车辆状态管理器」，它需要读取车速、发动机转速、油门位置等信息。传统做法是：

class VehicleStateManager {
    CanBus canBus;  // 直接依赖具体硬件
    EngineControlUnit ecu;
    
    void update() {
        speed = canBus.readSpeed();
        rpm = ecu.readRPM();
    }
};

这有什么问题？

  • 如果 CanBus 换了协议，你得改 VehicleStateManager
  • 如果 ECU 换了型号，你还得改 VehicleStateManager
  • 测试时，你得连上真硬件才能跑

用依赖倒置怎么改？

// 定义抽象接口
class IVehicleDataSource {
public:
    virtual float getSpeed() = 0;
    virtual float getRPM() = 0;
};

// 高层模块只依赖抽象
class VehicleStateManager {
    IVehicleDataSource& dataSource;  // 依赖抽象，不依赖具体
    
public:
    VehicleStateManager(IVehicleDataSource& ds) : dataSource(ds) {}
    
    void update() {
        speed = dataSource.getSpeed();
        rpm = dataSource.getRPM();
    }
};

// 低层模块也依赖抽象
class CanBusDataSource : public IVehicleDataSource {
    float getSpeed() override { /* CanBus读取 */ }
    float getRPM() override { /* CanBus读取 */ }
};

避坑指南：我曾经在一个项目中，把依赖倒置用过了头。每个类都抽象出一个接口，结果接口数量比实现类还多。代码读起来像在走迷宫。记住：依赖倒置是为了解耦，不是为了炫技。

4.4 三个原则如何配合使用

这三个原则不是孤立的。它们是一套组合拳。

原则 解决的问题 在汽车软件中的典型应用
模块化设计 功能耦合、职责不清 将诊断、通信、控制拆分为独立模块
接口抽象 实现细节变化导致上层改动 传感器接口、执行器接口、通信接口
依赖倒置 高层模块被低层模块绑架 应用层不依赖硬件驱动，只依赖抽象服务

我举个例子，把三者结合起来看。

假设你在做 AUTOSAR 架构中的 SWC（软件组件）。

  • 模块化：每个 SWC 只负责一个功能，比如「车速计算」
  • 接口抽象：SWC 通过 RTE（运行时环境）提供的接口通信，不直接调用 BSW
  • 依赖倒置：SWC 不依赖具体的硬件平台，只依赖抽象的服务接口

这样一来，同一个 SWC 可以复用到不同车型、不同硬件平台上。这才是真正的复用。

总结一下：模块化让你拆得清楚，接口抽象让你接得灵活，依赖倒置让你换得轻松。三个一起用，你的代码才能「一次设计，多处复用」。

嗯，今天就讲到这里。下一节我们聊聊「平台化架构设计」，到时候我会拿一个实际的项目案例来拆解。各位可以先想想：你现在的项目里，哪些地方可以应用这三个原则？

← 上一章 📖 返回目录 下一章 →