C++装饰器模式实战：告别继承爆炸，用层层包装优雅扩展功能

先说个真实场景。我前几年接手过一个日志组件，需求一开始就两个：往文件里写、往控制台里写。后来产品经理加功能，先是加缓存，然后要加密，再然后要校验和，最后还要压缩。最离谱的是，这些功能开关还得在运行时动态切换——测试环境只开缓存，生产环境要加密加校验，某些客户还要求全开。要按老写法，每加一个功能就派生子类，几轮迭代下来类会膨胀成什么样，我估计你们都能猜到。我当时重构用的方案，就是这篇要聊的装饰器模式。

这篇内容适合两类人：一类是刚学完C++语法，想弄明白设计模式在实际项目里到底怎么落地的同学；另一类是写过一阵子业务代码，正在被“继承爆炸”困扰，想找一条更干净扩展路径的开发者。我会把装饰器模式在C++里的完整实现思路、实际案例、典型坑位，以及现代C++下的几种“减重用法”都拆开讲清楚，让你看完就能上手改代码。

1. 为什么需要装饰器：继承“堆功能”的失控现场

很多初学者对设计模式的第一反应是“又多了一种花哨写法”，但装饰器模式恰恰是那种“你不主动用它，迟早会被迫重新造一个出来”的模式。要理解它的价值，得先看清楚继承在应对功能组合时的崩溃过程。

1.1 从一个小需求开始的类爆炸

假设我们要做一个数据写入组件，基础的数据源有两种：文件流和网络流。一开始需求很简单，就是“能写”。代码量很小，两个类就够：

class FileStream { public: void write(const std::string& data); }; class NetworkStream { public: void write(const std::string& data); };

然后需求来了：要给写入过程加缓冲。很多人第一时间想的是“继承它”：

class BufferedFileStream : public FileStream { // 重写write，先写进缓冲区 }; class BufferedNetworkStream : public NetworkStream { // 同上 };

看起来还行，两个新类而已。可下一个需求是加密，于是：

class EncryptedFileStream : public FileStream { ... }; class EncryptedNetworkStream : public NetworkStream { ... };

这时候还不算太离谱。但真正的灾难是“既要缓冲又要加密”——请问这个类从哪里继承？如果你从BufferedFileStream继承，那么BufferedNetworkStream那边的组合你还得再写一遍。

做个简单的排列组合：基础类型有2种，附加功能有3个（缓冲、加密、校验），那么需要的具体类数量是 2 × 2³ = 16 个。如果基础类型变成4种，附加功能变成5个，那就是 4 × 2⁵ = 128 个类。这还没算功能本身还有参数变体，比如加密算法A和加密算法B。

这就是典型的“继承堆功能”失控现场。你每增加一个附加功能，所有基础类型都得各自派生一遍；每增加一个基础类型，所有附加功能又得给它适配一遍。类数量呈指数级膨胀，代码重复几乎是必然的，而且一旦某个组合的逻辑要微调，你会发现自己根本找不到该改哪个类。

1.2 真正的问题：功能变化频率远高于类型变化频率

再仔细琢磨一下上面这个场景，会发现一个本质矛盾：基础类型（文件、网络）变化得慢，附加功能（缓冲、加密、校验）变化得快。

继承把“附加功能”硬编码进了类的继承树上，相当于把变化最频繁的维度提前固定死了。每来一个新附加功能，整棵继承树都要跟着动，这直接违背了开闭原则——对扩展开放、对修改关闭。

那有没有一种办法，让附加功能可以“即插即用”？这就是装饰器模式的核心思想：

• 把附加功能做成独立的包装类；
• 每个包装类持有被包装对象的引用；
• 包装类对外暴露相同的接口；
• 调用时由最外层逐层向内，最终落到原始对象上。

这个思路就像你去奶茶店点单：一杯基础茶底是“原始对象”，加珍珠、加奶盖、加芋泥就是一个个“装饰器”。你想加几个就加几个，不想加就只要茶底。老板不需要为了“珍珠奶盖芋泥茶”单独创建一个菜单项，因为任何组合都能用“茶底+装饰”拼出来。

2. C++实现装饰器的基础：接口、组件与两个角色

要把装饰器模式在C++里落地，先记住一句话：装饰器的存在前提是接口统一。如果被装饰的对象没有一个共同的抽象基类，装饰器就无从谈起，因为包装类没法在“接口层面”替代原始对象。

2.1 第一步：定义抽象接口

在C++里，这个抽象接口通常是一个含有纯虚函数的抽象类：

class Stream { public: virtual ~Stream() = default; virtual void write(const std::string& data) = 0; virtual void flush() = 0; };

我见过不少初学者在这里出错：他们图省事直接拿FileStream当基类，然后让装饰器继承FileStream。这样做有两个坏处：

1. 如果FileStream里有非虚成员函数，装饰器重写不了，接口就不统一了；
2. FileStream的构造函数可能有参数（比如文件名），装饰器被迫也要处理这些无关的参数，耦合度变高。

正确的做法是先抽象接口，再让所有具体组件和装饰器都实现这个接口。这个接口就是整条装饰链的“共同语言”。

2.2 具体组件：被装饰的原始对象

具体组件是装饰链的终点，它是真正干活的类，不需要知道装饰器的存在。拿数据流来说：

class FileStream : public Stream { public: explicit FileStream(const std::string& path) : path_(path) {} void write(const std::string& data) override { // 实际写入文件的逻辑 std::cout << "[File] write to " << path_ << ": " << data << "\n"; } void flush() override { std::cout << "[File] flush\n"; } private: std::string path_; };

注意，这个类重写的write和flush会在装饰链的最里层被调用。你可以在心里把装饰链想成一个洋葱，具体组件就是洋葱最里面的芯。

2.3 装饰器基类：那个“转发一切”的中间层

装饰器基类是理解这个模式的关键，也是最容易被忽略的部分。它的作用是：

• 持有一个指向Stream的指针（指向被包装的对象）；
• 默认把所有接口调用转发给被包装对象；
• 具体装饰器只重写它关心的那一个方法，其他方法继续走默认转发。

代码是这样的：

class StreamDecorator : public Stream { public: explicit StreamDecorator(Stream* wrapped) : wrapped_(wrapped) {} void write(const std::string& data) override { wrapped_->write(data); } void flush() override { wrapped_->flush(); } protected: Stream* wrapped_; };

这个“转发一切”的中间层价值非常大。如果没有它，每个具体装饰器都得把write和flush都重复实现一遍。有了它，具体装饰器只需要重写自己关心的行为。

用生活类比解释一下：装饰器基类就像一个公司前台，所有外部来电它都默认转给对应部门。新来的装饰器同事只需要告诉前台“我管哪条线”，而不是把所有线路都自己重新布一遍。

2.4 具体装饰器：在转发前后插入逻辑

有了基类，具体装饰器写起来非常清爽。比如加密装饰器：

class EncryptedStream : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string& data) override { // 在转发前，先把数据加密 std::string encrypted = encrypt(data); wrapped_->write(encrypted); // 或者直接调用 write 的默认转发 } void flush() override { wrapped_->flush(); } private: static std::string encrypt(const std::string& data) { // 示意代码，真正的加密算法按需替换 std::string result = data; for (char& c : result) c = static_cast<char>(c ^ 0x5A); return result; } };

同样，缓冲装饰器可以在write之前先攒数据，在flush时一次性写出：

class BufferedStream : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string& data) override { buffer_ += data; if (buffer_.size() >= 1024) { wrapped_->write(buffer_); buffer_.clear(); } } void flush() override { if (!buffer_.empty()) { wrapped_->write(buffer_); buffer_.clear(); } wrapped_->flush(); } private: std::string buffer_; };

注意这里的调用次序：装饰器在转发前做前置处理，在转发后做后置处理，这也是装饰器能层层叠加、灵活控制行为次序的根本原因。

3. 实战案例：给数据流做一层透明的“加工流水线”

前面讲了理论，这一节直接上完整案例。我以一个日志写入管线为例，把装饰器模式的组合方式、调用链、以及藏在细节里的坑都铺开讲。

3.1 需求拆解：日志组件为什么会变成“流水线”

先看需求背景。一个日志系统，基础写入目标是文件。随着项目演进，陆续出现这些附加需求：

如果这些需求是同时要开的，用继承会写出多少个类就不用多说了。用装饰器模式，我们只需要实现4个装饰器类，然后在运行时自由拼装。

3.2 完整实现代码

我这里把接口、基础组件和所有装饰器都写了一遍，代码不多，但每行都值得看。为了省篇幅，各装饰器的算法都用了示意实现，真实项目里替换成对应的库调用即可：

#include <iostream> #include <string> #include <memory> #include <vector> // 抽象接口 class Stream { public: virtual ~Stream() = default; virtual void write(const std::string& data) = 0; virtual void flush() = 0; }; // 具体组件：文件流 class FileStream : public Stream { public: explicit FileStream(std::string path) : path_(std::move(path)) {} void write(const std::string& data) override { std::cout << "[File:" << path_ << "] " << data << "\n"; } void flush() override { std::cout << "[File:" << path_ << "] flush\n"; } private: std::string path_; }; // 装饰器基类 class StreamDecorator : public Stream { public: explicit StreamDecorator(Stream* wrapped) : wrapped_(wrapped) {} void write(const std::string& data) override { wrapped_->write(data); } void flush() override { wrapped_->flush(); } protected: Stream* wrapped_; }; // 具体装饰器1：缓冲 class BufferedStream : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string& data) override { buffer_ += data; if (buffer_.size() >= 1024) { wrapped_->write(buffer_); buffer_.clear(); } } void flush() override { if (!buffer_.empty()) { wrapped_->write(buffer_); buffer_.clear(); } wrapped_->flush(); } private: std::string buffer_; }; // 具体装饰器2：加密 class EncryptedStream : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string& data) override { wrapped_->write(encrypt(data)); } void flush() override { wrapped_->flush(); } private: static std::string encrypt(const std::string& data) { std::string result = data; for (char& c : result) c = static_cast<char>(c ^ 0x5A); return result; } }; // 具体装饰器3：校验和 class ChecksumStream : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string& data) override { uint32_t sum = checksum(data); wrapped_->write(data + "|" + std::to_string(sum)); } void flush() override { wrapped_->flush(); } private: static uint32_t checksum(const std::string& data) { uint32_t sum = 0; for (char c : data) sum += static_cast<unsigned char>(c); return sum; } }; // 具体装饰器4：压缩 class CompressedStream : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string& data) override { wrapped_->write("[compressed:" + data + "]"); } void flush() override { wrapped_->flush(); } };

3.3 运行时拼装：不同环境组合不同

装饰器模式最大的好处，就是拼装动作可以放到运行时。同样的四个装饰器类，不同环境可以配出不同的链。比如开发环境只开缓冲，生产环境缓冲+加密+校验，还要压缩：

int main() { // 开发环境：只加缓冲 auto dev_stream = std::make_unique<BufferedStream>( new FileStream("dev.log") ); // 生产环境：缓冲 + 加密 + 校验 + 压缩 auto prod_stream = std::make_unique<CompressedStream>( new ChecksumStream( new EncryptedStream( new BufferedStream( new FileStream("prod.log") ) ) ) ); prod_stream->write("user login event"); prod_stream->flush(); return 0; }

调用prod_stream->write(...)时，实际的数据流向是这样的：

1. CompressedStream::write：先把数据标记为压缩；
2. 转发给ChecksumStream::write：计算校验和并拼到数据尾部；
3. 转发给EncryptedStream::write：整体加密；
4. 转发给BufferedStream::write：攒进缓冲区；
5. 缓冲区攒够时，转发给FileStream::write：真正写盘。

你可以把这条链想成工厂流水线：每个装饰器都是一个工位，每个工位只负责一道工序，最后流到组装车间完成落盘。想调整工序，只需要改变工位的“排列顺序”。

3.4 组合顺序不是小事：先加密还是先压缩？

这里有个特别容易忽略的点：装饰器的顺序直接决定语义。

还拿上面的生产环境配置举例子。如果顺序是“压缩 → 加密 → 校验”，那么校验和是对加密后的数据计算的；反过来如果先“校验”再“加密”，校验和就是基于明文计算的。这两种方案在数据完整性验证时的行为完全不同：

• 如果在加密前校验，解谜后校验和就能直接用于完整性校验；
• 如果在加密后校验，那校验和本身是加密的，校验时需要先解密才能比对。

没有绝对的“哪个更好”，但你必须清楚每种顺序的实际效果，并且要在文档或配置里把顺序固定下来。我见过有项目因为在多处代码里以不同顺序拼装装饰器，导致数据写出来格式不一致，排查了整整一天。建议把所有拼装逻辑收敛到一个工厂函数或者配置文件里，别散落在各个调用点。

3.5 这个案例暴露的几个经典坑

第一个坑：忘了定义虚析构函数。装饰器链是通过基类指针管理的，如果Stream没有virtual ~Stream()，通过Stream*删除派生类对象时，派生类析构函数不会被调用，轻则资源泄漏，重则程序崩溃。前面代码里我已经写了，但这里强调一下：这个不是可选项，是必须项。

第二个坑：装饰器链的所有权归属。上面的代码里，new FileStream(...)被传进装饰器，装饰器销毁时要不要负责销毁它包装的对象？这是装饰器模式在C++里最绕的问题。建议的做法是：用unique_ptr表达所有权转移，装饰器持有unique_ptr<Stream>而不是裸指针：

class StreamDecorator : public Stream { public: explicit StreamDecorator(std::unique_ptr<Stream> wrapped) : wrapped_(std::move(wrapped)) {} protected: std::unique_ptr<Stream> wrapped_; };

这样拼装时make_unique一层层包，所有权清晰，也不会出现“out了某个中间对象导致链断裂”的问题。如果你确实想用裸指针做“借用的引用”，那就要保证外部对象的生命周期一定长于装饰器链，并且在文档里写清楚，防止后续维护的人踩坑。

第三个坑：装饰器的拷贝行为。默认情况下，装饰器拷贝会把包装指针一并浅拷贝，两个装饰器可能指向同一个内部组件。如果其中一个链在执行write时改变内部状态，另一个链会看到“被篡改”的数据。通常我们会把装饰器设计为不可拷贝的（删除拷贝构造），或者用shared_ptr统一管理内部组件，按需选择。

4. 现代C++对装饰器模式的两种“减重方案”

经典 GoF 书里的装饰器模式是用虚函数和继承实现的，但到了现代C++，很多场景其实可以“轻量化”甚至“编译期化”。我根据自己的使用经验，整理了两条更贴合现代写法的路径，供你参考。

4.1 std::function + lambda 的轻量版装饰

很多项目的实际需求，并不是要给某个类体系加多个装饰器，而是想给某一个函数调用加额外的行为，比如打印耗时、加日志、失败重试。这种情况再上一整套StreamDecorator类体系，确实有点杀鸡用牛刀。用std::function加 lambda 就够了，写法非常直接：

#include <functional> #include <iostream> #include <chrono> // 原始函数 void sendRequest(const std::string& url) { std::cout << "send request to " << url << "\n"; } // 一个“装饰器”工厂：给任意函数加耗时统计 template <typename Func> auto withTiming(Func&& func) { return [func = std::forward<Func>(func)](auto&&... args) { auto start = std::chrono::high_resolution_clock::now(); func(std::forward<decltype(args)>(args)...); auto end = std::chrono::high_resolution_clock::now(); auto elapsed = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count(); std::cout << "elapsed: " << elapsed << " us\n"; }; } int main() { auto timedSend = withTiming(sendRequest); timedSend("https://example.com"); return 0; }

这种写法本质上是“函数式装饰器”，它灵活、开销小、不用定义类，适合装饰点比较集中的场景。它不适合的场景是：多个方法需要一起被包装（比如write和flush要同时被装饰），或者装饰器本身还要参与运行时拼装链并保持对象状态。一句话总结：装饰的是函数，用lambda；装饰的是对象体系，用类装饰器。

4.2 模板与CRTP：把装饰挪到编译期

如果你的装饰组合在编译期就能确定，不需要在运行时动态切换，那么可以用模板实现“零运行时开销”的静态装饰。最典型的思路是CRTP（奇异递归模板模式）：

template <typename Base> class EncryptedDecorator : public Base { public: using Base::Base; void write(const std::string& data) { Base::write(encrypt(data)); } private: static std::string encrypt(const std::string& data) { std::string result = data; for (char& c : result) c = static_cast<char>(c ^ 0x5A); return result; } }; template <typename Base> class BufferedDecorator : public Base { public: using Base::Base; void write(const std::string& data) { buffer_ += data; if (buffer_.size() >= 1024) { Base::write(buffer_); buffer_.clear(); } } void flush() { if (!buffer_.empty()) { Base::write(buffer_); buffer_.clear(); } Base::flush(); } private: std::string buffer_; }; // 直接通过模板参数规定装饰顺序 using EncryptedBufferedFileStream = EncryptedDecorator<BufferedDecorator<FileStream>>;

这个方案的优点很突出：没有虚函数调用，编译器在编译期就能完成所有类型解析，性能上几乎零损耗。但代价也很明显：组合成了类型的一部分。一旦你编译期确定了EncryptedBufferedFileStream，运行时就很难再改成“只缓冲不加密”的组合。所以它的适用范围是：行为策略相对固定、性能要求很高的场景。

4.3 运行时装饰 vs 编译期装饰怎么选

我自己在项目里的经验，可以用下面这个表格做快速判断：

大部分业务系统、中间件、日志库选运行时装饰就够了；只有底层网络库、高频数据通路这类环境，才值得考虑编译期装饰。

5. 装饰器与邻近模式的边界，以及实战中的选型经验

设计模式学到后面，最让人头疼的不是“怎么实现”，而是“该不该用”以及“和另一个模式长得太像怎么办”。装饰器、代理、适配器这三种模式，在类图上看都差不多，都是“包了一层”，但它们解决的问题完全不同。

5.1 装饰器、代理、适配器的差异

要记住一句话：装饰器改变功能，代理控制访问，适配器转换接口。判断标准也很简单：如果你包装之后对外仍然暴露同一个接口、核心行为不变只是增加附加行为，那是装饰器；如果你在调用前面加了一道“门卫”，条件是能过才放行，那是代理；如果你把A接口翻译成B接口，那是适配器。

我见过一个真实的项目里，有人用装饰器去做了权限校验：某个请求来的时候先检查token，不过就拒绝。其实这个场景用代理模式更贴切，因为权限校验不是“附加能力”，而是一种“访问控制”。虽然实现上几乎一样，但语义不同会直接影响代码的可读性和维护性。

5.2 我什么时候会用装饰器，什么时候不会

这几年用下来，我给自己定了几条很朴素的选择标准，分享给你：

第一，当附加功能的组合是排列组合时，无脑用装饰器。比如前面讲的流处理，8种基础类型×5种附加功能，不用装饰器就是类爆炸。

第二，当附加功能之间有明确的先后依赖时，谨慎用装饰器。比如说先压缩再加密还是先加密再压缩，这个顺序必须有全局约定，不能把选择权完全交给调用方。如果顺序错了会导致数据不可用，我倾向于把一种“标准顺序”固化到工厂函数里，只允许调用方做有限的顺序选择，而不是全开放。

第三，当功能本身是“二选一”的替代策略时，用策略模式而不是装饰器。比如日志可以输出到文件，也可以输出到网络，这两个是平级的，不是层层包装的关系，适合用策略或者简单的接口分派，硬套装饰器反而绕。

第四，当嵌套层数超过3层时，我会停下手来想想。装饰器本身是灵活的，但过深的链会让调用栈极难追踪。调试的时候你会面对一长串 `A::write -> B::write -> C::write -> D::write -> ...

`，每一层都得仔细看。如果你发现自己要加第四个装饰器了，建议先问一句：是不是应该把这些行为组合成一个独立的服务对象，而不是继续往链上挂节点。

5.3 保持装饰器健康的几条维护建议

代码写出来是一时的，怎么让后来的人（包括三个月后的自己）能轻松维护才是关键。我自己会坚持这几条：

• 一个装饰器只干一件事。缓冲就只管攒数据和刷盘，不要顺手在里面加格式转换。职责混在一起之后，组合顺序就变成“黑盒”，业务根本没法猜数据到底经过了哪些变化。
• 命名要一眼能看出是包装。BufferedStream、EncryptedStream、ChecksumStream，后缀Stream表明它是流体系的一员，前缀表明加了什么料。命名清晰能省去读者大量猜测。
• 每个装饰器要有独立的单元测试，也要有组合测试。单个装饰器测好后，能确保“每层工位都没问题”；组合测试则专门验证多装饰器一起工作时数据流转是否符合预期。尤其是顺序相关的组合，我会写死几个顺序样本，防止后续维护时有人随手改了拼装顺序。

另外还有一个调试技巧：可以在装饰器基类里加一个std::string debugName_，或者提供一个debugPrint()方法，打印出当前装饰链的层级。这在排查调用链时非常救命。

6. 更进一步的玩法：利用范畴思想看装饰器

前面聊的都是实战向的，最后我想提一个算是进阶视角的东西。如果你把装饰器模式放到范畴论的框架里看，会发现它其实和“函子”这个概念非常相似——一个包装结构，在其上可以继续施加变换，且变换可以复合。当然，日常C++工程里聊范畴论有点过于理论了，但它能给你一个启发：

装饰器并不只是“类包装类”这么简单。当你写下auto newObj = decorator(originalObj)这种形式的代码时，其实就是在表达“给某个东西的外层加上一个变换层”。坚持用这种统一的视角看待装饰器，你会发现它能应用的地方远比GoF书里的那几个例子广：从日志记录、缓存管理、重试机制，到数据校验、性能埋点、权限提示，都可以用同一种“包装”思维解决。

我个人的看法是：装饰器模式是C++开发者最值得熟练掌握的三个模式之一（另外两个是策略模式和观察者模式）。它不是“老古董设计书里的过时概念”，而是你在写真实项目时随时可能靠它自救的工具。尤其是当需求开始疯狂叠加、而你又不想把代码改成一锅粥的时候，装饰器就是那根帮你把复杂度拆回正确形状的杠杆。

希望这篇能把你的“第一行装饰器代码”引上路。别急着把工程里所有继承都改成装饰器，先找出一个真正符合“附加功能在运行时变化”的场景，动手写一次，你就会明白这种包装思想的威力。