C++装饰器模式详解：告别继承爆炸，用组合优雅叠加功能

我先把话说在前面：如果你现在写 C++，遇到“给对象加功能”的需求第一反应是开一个新子类，那这篇文章值得你花十分钟看完。不是说继承有罪，而是你大概率正在经历的那条路——类数量爆炸、功能排列组合、改一个基础功能牵一发而动全身——在遇到第三个叠加需求时就会让代码变得很难看。装饰器模式在 C++ 里是一个被低估的设计模式，因为很多教程把它讲得很抽象，其实核心就是一句话：把功能一层一层包在外边，像糖葫芦一样，调用时从外往内穿，返回时从内往外传。这篇我结合自己的实际项目经验，从原理、三种实现形态、一个完整的数据流例子、常见坑和同类模式辨析这五个角度看，希望能帮你在 C++ 里把装饰器用得顺手。

1. 先从一段让人头大的代码说起：装饰器要解决的到底是什么

1.1 没加装饰器之前，我们是怎么写功能叠加的

假设你有一个网络数据源类，职责很简单：往某个地方写一段数据。刚开始需求简单，你可能直接写一个 NetworkSource，内部一个 writeData(const std::string&) 搞定。代码长这样：

cpp复制class NetworkSource {
public:
    virtual ~NetworkSource() = default;
    virtual void writeData(const std::string& data) {
        // 真实逻辑：把 data 通过 socket 发出去
        std::cout << "Network write: " << data.size() << " bytes" << std::endl;
    }
};

到这里一切都很清爽。但需求从来不会停在第一个版本。下一个迭代，有人告诉你“写数据之前先统计一下写入次数”，于是你往 NetworkSource 里加了一个 counter_ 成员，在 writeData 里计数。再下一个迭代，数据要加密之后才能走网络，你又往方法里加了加密逻辑。再下一个迭代，要加缓存、要加日志、要加压缩……你看着这个类，发现它已经从“网络写入”变成了“网络写入+统计+加密+缓存+日志+压缩”的六合一巨无霸。接口参数越来越多，职责越来越模糊。这就是最原始的痛点：直接改原类，会把一个单一职责的类变成多功能杂烩。

1.2 继承方案为什么撑不住

有人会说，我不改原类，我用继承不就行了？于是你定义：

cpp复制class StatisticNetworkSource : public NetworkSource { ... };  // 统计
class EncryptedNetworkSource : public NetworkSource { ... };  // 加密
class CacheNetworkSource : public NetworkSource { ... };      // 缓存

三个功能，三个子类。看起来还好。但需求总是叠加的：要“统计+加密”怎么办？你新建 StatisticEncryptedNetworkSource。要“加密+缓存”？新建 EncryptedCacheNetworkSource。要“统计+加密+缓存”？再建一个……这里有个简单的数学事实：如果你有 n 个相互独立、可以任意组合的功能，继承方案在最坏情况下需要创建 (2^n - 1) 个子类才能覆盖所有组合。3 个功能是 7 个类，5 个功能就是 31 个类，10 个功能是 1023 个类。而且这些类名长到没法看，代码里大量重复转发逻辑。继承确实能复用“能力”，但它把功能组合的维度焊死在了类继承树上，每增加一个组合就是一次硬编码。

1.3 装饰器的核心思路：组合包裹，而不是继承扩展

装饰器模式换了一个思路：不把功能塞进继承树，而是把被装饰对象用指针包起来，每个装饰器只负责自己的那部分增强，然后转发给内部对象。比如加密装饰器，它只管把数据加密，然后调用内部对象的 writeData；统计装饰器只管计数，然后调用内部对象的 writeData；缓存装饰器只管查缓存，没命中时再调用内部对象。每个类都只做一件事，类数量线性增长，而不是指数增长。

你可以这样理解：装饰器是一条生产线，最内层的对象是毛坯件，每一层装饰器是一个加工工位，数据从最外层进去，一层层处理，最终落到最内层；结果从最内层返回，再一层层处理出来。用生活化类比，就是奥利奥饼干：饼干是核心组件，夹心是一层装饰，再裹一层巧克力又是一层装饰，你随时可以决定裹几层。这个设计比继承灵活的地方在于，组合发生在运行期，你可以在不修改源代码的前提下，自由拼装出不同的行为组合。

1.4 装饰器模式的四个角色，用一张图说清

• Component：抽象接口，定义被装饰对象和装饰器共同遵守的行为。在 C++ 里通常是一个虚基类，比如 DataSource。
• ConcreteComponent：真正干活的类，实现 Component 接口，比如 NetworkSource、FileDataSource。
• Decorator：装饰器基类，继承 Component，内部持有 Component* 或 unique_ptr<Component>，把接口调用转发给内部对象。
• ConcreteDecorator：具体装饰器，继承 Decorator，在转发前后加入自己的增强逻辑。

记住这个四角色划分，后面写代码会非常顺手。

2. C++ 里实现装饰器的三种主流形态：虚基类、模板、std::function

2.1 经典 Gof 方式：抽象基类 + 装饰器基类

这是最原汁原味的实现方式，设计模式书上写的就是这套。我先给一个可以完整编译跑起来的例子，再解释几个 C++ 特有的关键点。

cpp复制#include <iostream>
#include <memory>
#include <string>

// 1. Component：抽象接口
class DataSource {
public:
    virtual ~DataSource() = default;
    virtual void writeData(const std::string& data) = 0;
    virtual std::string readData() = 0;
};

// 2. ConcreteComponent：真正写文件的类
class FileDataSource : public DataSource {
public:
    explicit FileDataSource(std::string filename) : filename_(std::move(filename)) {}

    void writeData(const std::string& data) override {
        // 真实项目里这里是 ofstream 写文件
        std::cout << "[File] write " << data.size() << " bytes to " << filename_ << std::endl;
    }

    std::string readData() override {
        // 真实项目里这里是 ifstream 读文件
        return "file-data";
    }

private:
    std::string filename_;
};

// 3. Decorator：装饰器基类，关键是把接口转发给内部对象
class DataSourceDecorator : public DataSource {
public:
    explicit DataSourceDecorator(std::unique_ptr<DataSource> wrappee)
        : wrappee_(std::move(wrappee)) {}

    void writeData(const std::string& data) override {
        wrappee_->writeData(data);
    }

    std::string readData() override {
        return wrappee_->readData();
    }

protected:
    std::unique_ptr<DataSource> wrappee_;
};

// 4. ConcreteDecorator：加密装饰器
class EncryptionDecorator : public DataSourceDecorator {
public:
    using DataSourceDecorator::DataSourceDecorator;

    void writeData(const std::string& data) override {
        auto encrypted = encrypt(data);
        wrappee_->writeData(encrypted);
    }

    std::string readData() override {
        return decrypt(wrappee_->readData());
    }

private:
    static std::string encrypt(const std::string& s) {
        return "[encrypted:" + s + "]";
    }

    static std::string decrypt(const std::string& s) {
        if (s.rfind("[encrypted:", 0) == 0 && s.back() == ']') {
            return s.substr(11, s.size() - 12);
        }
        return s;
    }
};

// 4. ConcreteDecorator：统计装饰器
class CounterDecorator : public DataSourceDecorator {
public:
    using DataSourceDecorator::DataSourceDecorator;

    void writeData(const std::string& data) override {
        ++write_count_;
        wrappee_->writeData(data);
    }

    std::string readData() override {
        ++read_count_;
        return wrappee_->readData();
    }

    void report() const {
        std::cout << "[Counter] writes=" << write_count_
                  << ", reads=" << read_count_ << std::endl;
    }

private:
    size_t write_count_ = 0;
    size_t read_count_ = 0;
};

int main() {
    auto source = std::make_unique<CounterDecorator>(
        std::make_unique<EncryptionDecorator>(
            std::make_unique<FileDataSource>("a.txt")));

    source->writeData("hello world");
    auto data = source->readData();
    std::cout << "read result: " << data << std::endl;

    // 需要用 dynamic_cast 才能拿到统计信息，这是后文会讨论的一个点
    auto* counter = dynamic_cast<CounterDecorator*>(source.get());
    if (counter) {
        counter->report();
    }
    return 0;
}

这个例子里我重点想强调几个细节：

• DataSourceDecorator 内部持有的是 std::unique_ptr<DataSource>，不是裸指针。这是现代 C++ 写装饰器的默认选择。裸指针的版本不是不能用，但你要自己操心生命周期，很容易出现 double delete 或者悬挂指针。
• 构造函数用的是构造注入，即把被装饰对象作为参数传入。这样 CounterDecorator 创建出来就是一个完整可用的对象，不会出现“创建了但还没设置目标”的半初始化状态。
• 每个具体装饰器只做自己的增强，然后调用 wrappee_ 转发。转发不是可有可无的，漏掉转发的话整个链条就断了。

2.2 模板 / CRTP 方式：编译期组合，性能更极致

上面这个经典方式有个性能代价：每次调用都经过两三层虚函数跳转。如果你对性能敏感，并且装饰链在编译期就完全确定，可以用模板实现。核心思路是把装饰器写成模板类，模板参数是被装饰类型，这样整个组合在编译期就确定了类型，没有虚函数开销。

cpp复制template <typename Component>
class EncryptionDecorator : public Component {
public:
    using Component::Component;

    void writeData(const std::string& data) override {
        auto encrypted = encrypt(data);
        Component::writeData(encrypted);
        // 这里调用的是模板参数 Component 的 writeData，编译期就确定，不经过虚表
    }

    std::string readData() override {
        return decrypt(Component::readData());
    }

private:
    static std::string encrypt(const std::string& s) { return "[encrypted:" + s + "]"; }
    static std::string decrypt(const std::string& s) {
        if (s.rfind("[encrypted:", 0) == 0 && s.back() == ']') {
            return s.substr(11, s.size() - 12);
        }
        return s;
    }
};

// 用法
using EncryptedFile = EncryptionDecorator<FileDataSource>;
EncryptedFile source("b.txt");
source.writeData("hello");

模板方式的优势是性能好、类型安全，代码在编译器就把叠加关系确定了，运行期不需要动态分配任何装饰器对象。缺点是装饰链一旦写成 using 就固定死了，无法在运行期动态调整。所以说它是“编译期装饰器”，适合那种确实非常确定、不需要切换组合方式的场景。

2.3 std::function 形式的轻量装饰链

如果只是给函数级别的操作加装饰，比如前置日志、后置计时、参数校验，可以用 std::function 写出一个非常轻量的“管道式”装饰链。这种形式不太像传统设计模式，但现代 C++ 项目里很常见。

cpp复制struct DataChannel {
    std::function<void(const std::string&)> writer;
    std::function<std::string()> reader;
};

DataChannel addEncryption(DataChannel inner) {
    DataChannel out;
    out.writer = [inner](const std::string& data) {
        std::string encrypted = "[encrypted:" + data + "]";
        inner.writer(encrypted);
    };
    out.reader = [inner]() {
        auto raw = inner.reader();
        return raw.substr(11, raw.size() - 12);
    };
    return out;
}

DataChannel addCounting(DataChannel inner) {
    DataChannel out;
    out.writer = [inner](const std::string& data) {
        std::cout << "[Counter] write called" << std::endl;
        inner.writer(data);
    };
    return out;
}

int main() {
    DataChannel base;
    base.writer = [](const std::string& data) {
        std::cout << "Base write: " << data << std::endl;
    };

    auto channel = addEncryption(addCounting(base));
    channel.writer("hello");
    return 0;
}

std::function 方式的魅力在于它不需要预先定义装饰器类，lambda 就完成了装饰逻辑，叠加顺序看代码调用就一目了然。缺点是它是函数级别的组合，如果装饰器需要持有状态（比如计数、缓存池），用 lambda 捕获会略显笨拙，而且 std::function 本身有分配和调用开销。我一般把它用在脚本系统、插件系统这类对结构要求不严格、强调灵活性的地方，而不是核心 IO 路径。

2.4 三种形态怎么选

我自己的习惯是：默认用经典虚基类；如果在嵌入式或性能关键路径，且组合关系在编译期固定，用模板方式；如果装饰的粒度是“函数”而非“对象”，用 std::function 管道。三个不冲突，一个项目里混用很正常。

3. 一个贯穿全文的例子：可叠加的流式 IO 装饰链

3.1 需求场景：一个需要缓冲、压缩、加密、日志的数据通道

为了让你把上面的理论落到实践，我带你看一个我在日志采集系统里实际用过的结构。需求是这样的：底层一个 FilePipe 负责把字节流写到磁盘，但上层要求按需叠加四种能力：

• 缓冲：攒够一定字节再写盘，减少 IO 次数。
• 压缩：写盘之前把内容压缩。
• 加密：在网络传输或存储时保证数据不可读。
• 日志：记录每次写入的数据量和耗时。

这四个能力需要可以任意组合。比如开发环境想压缩但不加密，生产环境既压缩又加密还要日志。用继承的话，功能组合实在太多，显然应该用装饰器。

3.2 接口与组件设计

接口定义如下：

cpp复制class DataPipe {
public:
    virtual ~DataPipe() = default;
    virtual void write(const std::string& bytes) = 0;
    virtual std::string read() = 0;
};

最内层的 FilePipe 实现真正的文件读写：

cpp复制class FilePipe : public DataPipe {
public:
    explicit FilePipe(std::string path) : path_(std::move(path)) {}

    void write(const std::string& bytes) override {
        std::cout << "[FilePipe] write " << bytes.size() << " bytes to " << path_ << std::endl;
        // 实际项目：ofstream 写入
    }

    std::string read() override {
        // 实际项目：ifstream 读取
        return "file-bytes";
    }

private:
    std::string path_;
};

然后写一个 PipeDecorator 基类，所有装饰器都继承它：

cpp复制class PipeDecorator : public DataPipe {
public:
    explicit PipeDecorator(std::unique_ptr<DataPipe> inner) : inner_(std::move(inner)) {}

    void write(const std::string& bytes) override { inner_->write(bytes); }
    std::string read() override { return inner_->read(); }

protected:
    std::unique_ptr<DataPipe> inner_;
};

3.3 具体装饰器实现要点

缓冲装饰器要注意“攒积分”。它的 write 不直接转发，而是先把数据塞进缓冲区，等缓冲区满了再一次性写入。read 需要先读底层数据，再按缓冲语义返回。为了不引入复杂状态，我这里的演示简化成“第一次写不转发，第二次才把两次的数据一起转发”：

cpp复制class BufferedPipe : public PipeDecorator {
public:
    using PipeDecorator::PipeDecorator;

    void write(const std::string& bytes) override {
        pending_ += bytes;
        if (pending_.size() >= buffer_size_) {
            inner_->write(pending_);
            pending_.clear();
        }
    }

    std::string read() override {
        return inner_->read();
    }

private:
    std::string pending_;
    size_t buffer_size_ = 64;
};

压缩装饰器和加密装饰器都是“转换”型：写的时候先转换，再把转换结果传给内部；读的时候先从内部读，再做反向转换。它们最大的区别是转换算法不同，装饰器框架完全一致。日志装饰器则往往在转发前后各做一件事：转发前记录 start 时间，转发后计算耗时并输出。

3.4 组装与使用：顺序是个严肃的问题

现在到了关键部分。同一个装饰器集合，组装顺序不同，最终行为完全不同。比如先压缩再加密和先加密再压缩，前者压缩率高（因为加密后的数据熵很高，几乎压不动），后者存储开销更大但可能便于在加密层看日志时辨认内容。下面是一条组装顺序的示例：

cpp复制auto pipe = std::make_unique<LoggingPipe>(
    std::make_unique<EncryptionPipe>(
        std::make_unique<CompressionPipe>(
            std::make_unique<BufferedPipe>(
                std::make_unique<FilePipe>("data.bin")))));

这里调用的顺序是：LoggingPipe::write → EncryptionPipe::write → CompressionPipe::write → BufferedPipe::write → FilePipe::write。数据流向从外到内。而 read 的方向正好相反：FilePipe::read 返回原始字节，经 BufferedPipe、CompressionPipe（解压）、EncryptionPipe（解密）、LoggingPipe 逐层处理后返回。所以“顺序”这件事从两层理解：写链路是一个方向，读链路是反方向，你在设计装饰器时必须成对考虑 write/read 的转换，不能只重写一个方向。

3.5 如果改用继承，代码会膨胀到什么程度

我算了一笔账：4 个独立功能，组合情况是 (2^4 - 1 = 15) 种（不算完全无装饰的基础类）。用继承就需要 15 个具体类，而且每个类都要处理转发逻辑。功能变成 5 个，就是 31 个类。这不是“代码量大”，而是“不可能维护”：每增加一个功能点，类数量翻倍。装饰器模式下，增加一个功能只需要新增一个装饰器类，已有的类和调用方代码完全不用动。这正是开闭原则“对扩展开放，对修改关闭”的直接体现。实际项目里，这个 IO 装饰链用了三个月后，产品又加了“校验和”功能，我只写了一个 ChecksumPipe，一行现有代码没改就接了上去。

4. 踩过的坑：拷贝语义、const 正确性与装饰链顺序

4.1 资源管理：双重释放的根源

很多初学装饰器的读者第一次用裸指针实现时，会在 ~Decorator() 里 delete inner_，然后在 main 里又 delete 了一次被装饰对象，于是 double free。我的建议非常明确：现代 C++ 默认全部使用 std::unique_ptr 管理被装饰对象。装饰器析构时，unique_ptr 自动释放链内所有对象，不需要手动写析构函数。如果你需要多个装饰器共享同一个最内层对象（比如多个统计器观察同一个数据源），那用 std::shared_ptr 替代，但一般情况下 unique_ptr 已经够用。另外别忘了给基类 DataSource / DataPipe 声明虚析构函数，否则通过基类指针 delete 派生类时是未定义行为。

4.2 const 正确性：一个细节引发的连锁问题

装饰器内部的转发方法应该声明为 const 吗？这个问题看似简单，实际非常容易踩雷。如果 writeData 不修改对象状态，它确实可以声明为 const。但一旦装饰器需要计数、缓存这类状态，writeData 就会修改成员变量，这时它不能是 const。麻烦的是，有时候接口设计是 const DataSource&，而装饰器内部持有的 unique_ptr<DataSource> 是非 const 的，如果你在 const 成员函数里通过 wrappee_->writeData(...) 调用，编译器会报错，因为 const 函数内部只能调用被指对象的 const 成员函数。

我的建议是：接口设计从一开始就要想清楚哪些装饰器会持有可变状态。凡是要写计数、缓存、缓冲区的装饰器，write / read 就保持非 const。如果想要一个既能读又能统计的“只读视图”，可以在装饰器上单独提供一个 snapshot() const 方法，而不是把所有接口都搞成 const。否则为了迁就 const，会让装饰器内部的 mutable 泛滥，反而失去 const 带来的编译期约束。

4.3 装饰链顺序：为什么压缩后加密和加密后压缩完全不同

这是个经典坑。压缩算法利用数据中的重复模式，加密算法要把数据变成近似随机的序列。如果你先加密再压缩，加密后的数据熵很高，压缩率极低，甚至比原数据还大；先压缩再加密会好很多。另一个例子是日志装饰器：如果放在最外层，日志记录的是最终发送的数据长度；如果放在最内层，记录的是原数据长度。两种统计口径不同，排查问题时差别很大。所以每一条装饰链都不是随便拼出来的，要有明确的语义模型。我一般会在代码评审里要求写清“这条链为什么是这个顺序”，让后来者能理解设计意图。

还有一个容易忽略的点：装饰器链的构建通常发生在对象创建时。如果你用工厂函数返回 unique_ptr<DataSource>，最好把装饰链的组装逻辑收敛到工厂内部，不要散落在业务代码里。这样既便于统一调整顺序，也方便测试时替换组件。

4.4 构造注入优于 set 注入

Decorator 可以通过构造函数注入目标对象，也可以通过 setter 注入。我强烈推荐构造注入。原因很简单：装饰器的前提是“它必须包着一个东西”，没有内部对象的装饰器是不完整的。构造函数注入保证对象一创建就处于完整状态，不会出现“创建了装饰器但忘了 set 目标”这种运行期才发现的问题。如果你确实需要在运行期换掉内部对象，可以用 reset() 方法，但默认路径必须是构造注入。

4.5 调试深层装饰链的经验

装饰器链一旦超过三层，调试时就容易晕。这里分享几个实操技巧：

• 在每个装饰器的构造析构里加 --name=ClassName 的日志，可以快速看到构造顺序。
• 给装饰器加一个 describe() 方法，返回 "Encryption(" + inner_->describe() + ")" 这样的字符串，组装出来就是一条完整的链描述，打日志非常直观。
• Debug 时在装饰器基类的转发函数上打断点，可以看到调用链逐层经过哪些类，比在具体实现里打断点更全面。
• 如果发现某个装饰器没生效，优先检查是不是忘了调用 inner_->xxx()。这个错误在转发类里极其常见，几乎每个写装饰器的人都会犯一次。

5. 装饰器和它的近亲们：什么时候真该用装饰器

5.1 与继承、策略、代理、组合模式的边界

很多读者把装饰器和其他几个结构相似的模式混在一起，这里我按实际语义排一个表：

判断标准其实很简单：如果你是在“调一个行为之前或之后做点附加操作”，这可能用装饰器，也可能用代理；如果你是在“换一种算法实现”，用策略模式；如果你要一次性给一棵树的所有节点加功能，考虑组合模式。这些模式不互斥，同一个系统里可以同时出现。

5.2 “过度装饰”的症状：装饰器不是越多越好

装饰器也不是万能药。当装饰链超过三四层时，调试成本、创建成本、调用开销都会上升。我有几个判断“装饰器过度”的信号：

• 某层装饰器只是透传，什么都没增强，那它就不该存在。
• 为了拿到某一层的特有功能，到处 dynamic_cast。这基本等于承认你的接口设计漏了方法。
• 装饰链的组装代码散落多处，同一个链被复写了七八次。这时候需要一个工厂函数。
• 装饰器之间隐含调用顺序依赖，比如 A 装饰器要求 B 装饰器必须先工作。这说明职责没有划分干净，应该把 A 和 B 合并，或者重新审视接口。

一个健康的装饰链通常不超过四层。需要更长时，我更倾向于拆分成两个不同的对象，或者用 std::function 管道把“处理器序列”显式表达出来，避免一层层嵌套让人看不清整体流程。

5.3 现代 C++ 环境下还有哪些替代方案

写装饰器并不是只能用继承 + 虚函数。现代 C++ 给了一些新思路：

• std::function 管道：上一节提到过，适合函数级装饰。
• std::variant 分派：如果组合类型在编译期已知，用 std::variant 而不是继承体系。
• 编译期策略模板：功能作为模板参数传入，编译期展开，零运行时开销。
• Facade / 中间件：用一层 Facade 包装整条装饰链，对外只暴露一个简单接口，内部自由组装。

我在实际项目里见过一个不错的折中：核心接口用 DataPipe 虚基类，对外暴露 createPipe(Options opts) 工厂函数，里面根据配置动态拼接不同装饰器。调用方完全不知道装饰链的存在，只拿到一个 DataPipe 对象。这样既保留了装饰器的灵活，又避免了调用方被嵌套构造的代码淹没。

5.4 面试和代码评审里容易被追问的边界问题

如果你在准备 C++ 面试，或者要在代码评审里向同事解释装饰器，这几个问题是几乎一定会被问到的：

1. 为什么构造函数注入比 setter 注入好？答：保证对象完整性，避免半初始化状态，符合 RAII 精神。
2. 装饰器和继承的本质区别是什么？答：继承是编译期静态复用，装饰器是运行期动态组合；继承会带来类数量爆炸，装饰器类数量线性增长。
3. 装饰器会不会破坏封装？答：不会，装饰器通过公开接口访问被装饰对象，不触碰内部私有状态，反而比“在基类里加开关”更符合封装。
4. 如果最内层对象要被多个装饰器共享，怎么办？答：使用 shared_ptr，或者将共享对象抽到一个独立组件中。
5. 现代 C++ 里装饰器一定要用虚函数吗？答：不一定，模板和 std::function 是有效的替代。

这些问题没有标准答案，关键是你在实际代码里试用过、体会过取舍。纸上谈兵最容易被追问卡壳。

我在实际项目里用装饰器模式最多的场景就是日志采集和中间件设计：缓冲、压缩、加密、拦截、审计，随便一列就是四五层。用得好的标准不是代码有多花哨，而是加新需求时你只需要新增一个类，所有既有调用方一行都不改。如果你现在正在为一个“多功能叠加”的类苦恼，试着把功能拆成装饰器，大概率会比你现在凝视着的一坨 switch-case 舒服得多。