设计原则在嵌入式系统中的应用：内存受限下的设计原则，静态多态与CRTP

嵌入式开发，说白了就是戴着镣铐跳舞。我做了十几年嵌入式软件，最深的体会就是：内存不是无限的，CPU也不是无限的。你那些在PC上跑得飞快的设计模式，搬到单片机上可能直接让系统崩溃。

今天咱们聊聊，在内存受限的环境下，怎么把面向对象设计原则用活。重点说说静态多态和CRTP——这两个东西，是我在项目里反复用、反复验证过的。

一、嵌入式系统的特殊约束

先说说嵌入式系统的痛点。你想想看，一个典型的MCU可能只有几KB的RAM，几十KB的Flash。在这种环境下，你没法像写桌面程序那样随意new对象、用虚函数表。

我遇到过最极端的情况：一个智能传感器项目，RAM只有2KB。连一个完整的TCP/IP协议栈都塞不下。那时候我就在想，设计原则到底该怎么落地？

说白了，我们需要一种「轻量级」的面向对象。不要虚函数表，不要动态分配，不要运行时类型识别。那用什么？用编译期多态。

二、静态多态：编译期就定下来的事

动态多态靠虚函数，运行时查虚函数表。静态多态靠模板，编译期就确定调用哪个函数。两者的区别，就像你提前订好机票（静态）和到了机场再买票（动态）。

静态多态的好处很明显：

• 零运行时开销——没有虚函数表指针，没有间接调用
• 内存占用小——每个对象省下一个指针（4或8字节）
• 编译器优化空间大——可以内联，可以死代码消除

我个人的习惯是：只要不涉及运行时多态需求，一律用静态多态。比如驱动层、协议栈底层、算法库，这些地方用模板比用虚函数好得多。

三、CRTP：奇特的递归模板模式

CRTP（Curiously Recurring Template Pattern）是静态多态的一种经典实现。它的核心思想很简单：派生类把自己作为模板参数传给基类。

template <typename Derived>
class SensorBase {
public:
    void init() {
        // 调用派生类的实现
        static_cast<Derived*>(this)->initImpl();
    }
    
    uint16_t read() {
        return static_cast<Derived*>(this)->readImpl();
    }
};

class TemperatureSensor : public SensorBase<TemperatureSensor> {
public:
    void initImpl() {
        // 初始化温度传感器硬件
        ADC_Init();
    }
    
    uint16_t readImpl() {
        return ADC_Read();
    }
};

class PressureSensor : public SensorBase<PressureSensor> {
public:
    void initImpl() {
        // 初始化压力传感器
        SPI_Init();
    }
    
    uint16_t readImpl() {
        return SPI_Read();
    }
};

你看，这里没有虚函数，没有虚函数表。每个SensorBase的实例就是它自己，没有额外的指针开销。编译器看到static_cast<Derived*>(this)->readImpl()，直接就能确定调用哪个函数，甚至可以内联。

四、CRTP vs 虚函数：一个对比

咱们用表格直观对比一下：

对比项	虚函数（动态多态）	CRTP（静态多态）
内存开销	每个对象多一个vptr指针（4/8字节）	零额外开销
调用开销	间接调用，无法内联	直接调用，可内联
灵活性	运行时决定类型	编译期决定类型
代码量	需要虚函数表，代码段略大	模板实例化，可能增加代码段
适用场景	运行时多态、插件式架构	编译期已知类型、性能敏感

嗯，这里要注意：CRTP不是银弹。它增加了编译时间，而且如果滥用，会导致代码膨胀。我一般只在以下情况用CRTP：

• 对象数量多（几十上百个）
• 调用频率高（中断服务函数里）
• 类型在编译期就完全确定

五、设计原则在嵌入式中的落地

咱们把几个核心设计原则，放到嵌入式场景里重新审视一下：

1. 开闭原则

在嵌入式里，开闭原则依然有效。但实现方式变了。不用抽象基类和工厂模式，而是用模板和策略模式。比如：

// 策略模式 + CRTP
template <typename Protocol>
class CommunicationManager {
public:
    void send(const uint8_t* data, size_t len) {
        Protocol::send(data, len);
    }
    
    void receive(uint8_t* buffer, size_t maxLen) {
        Protocol::receive(buffer, maxLen);
    }
};

class UARTProtocol {
public:
    static void send(const uint8_t* data, size_t len) {
        // UART发送
    }
    static void receive(uint8_t* buffer, size_t maxLen) {
        // UART接收
    }
};

class SPIProtocol {
public:
    static void send(const uint8_t* data, size_t len) {
        // SPI发送
    }
    static void receive(uint8_t* buffer, size_t maxLen) {
        // SPI接收
    }
};

这样，新增一个协议只需要写一个新的Protocol类，不需要修改CommunicationManager。开闭原则实现了，而且没有虚函数开销。

2. 单一职责原则

在嵌入式里，单一职责尤其重要。每个模块只做一件事，而且要做小。我见过最糟糕的代码：一个函数500行，既管GPIO又管定时器还管通信。这种代码在PC上可能还能跑，在嵌入式里就是灾难——没法测试，没法复用，没法优化。

3. 接口隔离原则

嵌入式里接口要尽量小。一个接口只暴露必要的操作。比如一个LED驱动，只需要on()、off()、toggle()三个方法就够了。不要搞什么getBrightness()、setColor()——除非你真的需要。

六、知识体系结构图

下面这张图，把本章的核心逻辑串起来了：

七、避坑指南

最后，分享几个我踩过的坑：

好了，这一章就聊到这里。静态多态和CRTP是嵌入式开发的利器，但要用对地方。记住：设计原则是指导，不是教条。在内存受限的环境下，找到最适合的平衡点，才是真正的架构能力。

---