1. 项目概述为什么我们需要装饰模式在C项目里摸爬滚打久了你肯定遇到过这种场景一个核心类功能稳定但需求方隔三差五就提新要求今天要加个日志明天要加个缓存后天又要支持性能监控。如果你每次都去修改这个核心类的源代码用不了多久这个类就会变得臃肿不堪各种功能耦合在一起牵一发而动全身维护起来简直是噩梦。更头疼的是有些功能组合是动态的、运行时才决定的比如这次请求需要“日志缓存”下次请求只需要“日志”用继承来实现这些功能组合会导致类爆炸比如LogCacheWidget,LogWidget,CacheWidget...。装饰模式Decorator Pattern就是为了优雅地解决这类“动态扩展对象功能”的问题而生的。它属于结构型设计模式其核心思想是在不改变原有对象结构的情况下动态地给一个对象添加一些额外的职责。就像给一个朴素的相框核心对象加上一层层不同的画框装饰器你可以选择加金边、加浮雕、加LED灯带这些装饰可以任意组合而且随时可以加上或取下完全不会损坏原来的相框。在C的语境下装饰模式通过组合和继承利用多态特性实现了功能的“即插即用”。它完美遵循了“开闭原则”对扩展开放对修改关闭让你能灵活应对变化的需求而不是通过修改既有的、稳定的代码。接下来我们就深入拆解这个模式的实现原理、在C中的典型写法以及那些只有踩过坑才知道的实战技巧。2. 核心思路与UML类图解析要理解装饰模式先得在脑子里建立起它的标准结构。我们可以把它想象成一个“俄罗斯套娃”或者“洋葱模型”。2.1 核心角色定义一个标准的装饰模式通常包含以下几个关键角色组件接口Component 这是所有对象的公共接口可以是抽象类或者纯虚接口。它定义了核心对象和装饰器对象共有的操作。在我们的相框比喻里这就是“可展示”这个行为。具体组件ConcreteComponent 这是我们要装饰的原始对象它实现了组件接口定义了核心的基础行为。比如那个最朴素的木头相框。装饰器基类Decorator 这是一个也实现了组件接口的抽象类。它的关键之处在于它内部持有一个指向组件接口的指针或引用。这个指针使得装饰器可以包裹一个组件对象无论是具体组件还是另一个装饰器。它通常会把所有操作委托给这个被包裹的对象但同时它也为子类定义了扩展功能的接口。具体装饰器ConcreteDecorator 继承自装饰器基类负责向组件添加新的职责。每个具体装饰器都会在调用被包裹对象的操作前后执行自己新增的逻辑。比如BorderDecorator负责加边框ShadowDecorator负责加阴影。2.2 标准UML类图与C映射虽然我们不能画图但可以用文字清晰地描述这个结构并对应到C代码Component (接口) | -- virtual void Operation() 0; | | 继承 | ConcreteComponent (具体组件) Decorator (装饰器基类) | | -- void Operation() override; -- Component* component_; // 关键组合一个组件 (实现核心逻辑) | -- void Operation() override { if (component_) component_-Operation(); } // 通常委托调用 | | 继承 | ConcreteDecoratorA ConcreteDecoratorB | | -- 添加新状态或行为 -- 添加新状态或行为 -- 在Operation中 -- 在Operation中 调用父类(Decorator)的 调用父类(Decorator)的 Operation并在其 Operation并在其 前后添加新逻辑。 前后添加新逻辑。C映射关键点Component: 通常是一个包含纯虚函数的抽象类class IComponent { public: virtual void execute() 0; }。组合关系:Decorator类中包含一个IComponent*或std::unique_ptrIComponent成员这是实现装饰能力的核心。委托调用:Decorator::execute()的实现中会调用component_-execute()。具体装饰器则先调用Decorator::execute()即委托给被装饰对象然后再执行自己的附加逻辑。多态链: 因为所有装饰器和具体组件都继承自IComponent所以你可以用ConcreteDecoratorA去包裹一个ConcreteDecoratorB而ConcreteDecoratorB又包裹着ConcreteComponent形成一条调用链。客户端代码只需要面对最外层的IComponent指针操作即可。这种结构的美妙之处在于装饰器对客户端是完全透明的。客户端只知道它在操作一个Component对象至于这个对象被层层包裹了多少功能客户端无需关心。3. C代码实现与逐行解读理论说再多不如一行代码来得实在。我们用一个经典的例子来演示一个数据输出流DataStream核心功能是写数据。我们需要动态地为其添加压缩CompressionDecorator和加密EncryptionDecorator功能。3.1 基础组件与具体组件实现首先定义我们的组件接口和最基本的具体组件。// Component.h - 组件接口 #ifndef COMPONENT_H #define COMPONENT_H #include string // 数据流接口定义核心操作 class IDataStream { public: virtual ~IDataStream() default; // 虚析构确保多态删除正确 // 核心操作写入数据 virtual void write(const std::string data) 0; // 可以添加read等其他操作此处为简化只写write }; #endif // COMPONENT_H// FileStream.h / FileStream.cpp - 具体组件文件流 #ifndef FILE_STREAM_H #define FILE_STREAM_H #include Component.h #include fstream #include iostream // 具体组件实现将数据写入文件 class FileStream : public IDataStream { public: explicit FileStream(const std::string filename) : filename_(filename) { // 构造函数中打开文件并非必须也可以在write时打开。这里演示简单初始化。 std::cout [FileStream] Opening file: filename_ std::endl; } ~FileStream() override { std::cout [FileStream] Closing file: filename_ std::endl; } void write(const std::string data) override { // 模拟写入文件的核心操作 std::cout [FileStream] Writing to file \ filename_ \: data std::endl; // 实际代码会是std::ofstream file(filename_, std::ios::app); file data; } private: std::string filename_; }; #endif // FILE_STREAM_H代码解读与注意事项接口设计IDataStream接口尽可能保持精简只定义最核心、最稳定的操作。这是设计模式成功的基础。虚析构函数基类的虚析构函数 (virtual ~IDataStream() default)至关重要。当通过基类指针删除派生类对象时它能确保调用正确的派生类析构函数避免内存泄漏。这是C多态编程的黄金法则之一。具体组件职责单一FileStream只关心一件事——把数据写到文件。它不应该知道任何关于加密或压缩的事情。3.2 装饰器基类实现这是装饰模式的核心枢纽它维护了指向被装饰对象的指针。// StreamDecorator.h - 装饰器基类 #ifndef STREAM_DECORATOR_H #define STREAM_DECORATOR_H #include Component.h #include memory // 使用智能指针管理生命周期 // 装饰器基类同样继承自IDataStream class StreamDecorator : public IDataStream { public: // 构造函数接收一个被装饰的流对象使用智能指针管理 explicit StreamDecorator(std::unique_ptrIDataStream stream) : stream_(std::move(stream)) { // std::move 转移所有权避免不必要的拷贝 } // 默认实现直接委托给被装饰的流对象 void write(const std::string data) override { if (stream_) { stream_-write(data); } } // 虚析构函数保证派生类对象能被正确销毁 virtual ~StreamDecorator() default; protected: // 保护成员允许派生类访问被装饰的流 std::unique_ptrIDataStream stream_; }; #endif // STREAM_DECORATOR_H关键点与实战技巧使用std::unique_ptr这是现代C管理资源所有权的推荐方式。它明确了StreamDecorator拥有stream_的所有权。当StreamDecorator对象销毁时stream_也会被自动销毁完美避免了原生指针可能带来的内存泄漏问题。std::move的使用在构造函数中我们使用std::move(stream)来转移传入的unique_ptr的所有权。这意味着调用者客户端在构造装饰器后就放弃了对原始流对象的所有权。这是装饰模式中对象“包裹”关系的直观体现。委托调用write方法的默认实现就是简单地调用stream_-write(data)。具体装饰器可以覆盖这个方法在调用前后添加自己的逻辑。3.3 具体装饰器实现现在我们来创建两个具体的装饰器加密装饰器和压缩装饰器。// EncryptionDecorator.h / .cpp #ifndef ENCRYPTION_DECORATOR_H #define ENCRYPTION_DECORATOR_H #include StreamDecorator.h #include string // 具体装饰器加密装饰器 class EncryptionDecorator : public StreamDecorator { public: // 继承基类构造函数 using StreamDecorator::StreamDecorator; void write(const std::string data) override { // 1. 执行加密操作此处为模拟 std::string encryptedData ENCRYPTED( data ); std::cout [EncryptionDecorator] Encrypting data. std::endl; // 2. 将加密后的数据传递给被装饰的流对象可能是基础流也可能是另一个装饰器 StreamDecorator::write(encryptedData); // 调用父类的write即委托调用 // 3. 可选加密后操作如记录日志 // std::cout [EncryptionDecorator] Encryption completed. std::endl; } }; #endif // ENCRYPTION_DECORATOR_H// CompressionDecorator.h / .cpp #ifndef COMPRESSION_DECORATOR_H #define COMPRESSION_DECORATOR_H #include StreamDecorator.h #include string // 具体装饰器压缩装饰器 class CompressionDecorator : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string data) override { // 1. 执行压缩操作此处为模拟 // 假设压缩后数据变短用COMPRESSED标记 std::string compressedData COMPRESSED[ data ]; std::cout [CompressionDecorator] Compressing data. std::endl; // 2. 将压缩后的数据传递给被装饰的流对象 StreamDecorator::write(compressedData); } }; #endif // COMPRESSION_DECORATOR_H实现细节与逻辑执行顺序装饰器的逻辑是在委托调用StreamDecorator::write之前执行的。这意味着对于EncryptionDecorator(CompressionDecorator(FileStream))这样的链执行顺序是先加密然后加密后的数据进入压缩装饰器被压缩最后压缩的结果被写入文件。装饰的顺序决定了功能的执行顺序这一点需要根据业务逻辑仔细设计。using声明using StreamDecorator::StreamDecorator;这行代码继承了基类的构造函数这样EncryptionDecorator就可以直接用std::unique_ptrIDataStream来构造代码更简洁。模拟操作在实际项目中encryptedData和compressedData会是真正的加密/压缩算法结果。这里用字符串包裹来模拟便于理解执行流程。3.4 客户端调用与组合演示最后我们看看客户端如何像搭积木一样使用这些组件。// main.cpp #include iostream #include memory #include “FileStream.h” #include “EncryptionDecorator.h” #include “CompressionDecorator.h” void clientCode(std::unique_ptrIDataStream stream) { // 客户端代码只依赖于抽象的IDataStream接口 std::cout \n--- Client is writing data --- std::endl; stream-write(Hello, Decorator Pattern!); std::cout --- Write operation finished ---\n std::endl; } int main() { std::cout Decorator Pattern Demo in C std::endl; // 场景1使用最基础的FileStream std::cout \n[Scenario 1] Plain File Stream: std::endl; auto plainStream std::make_uniqueFileStream(output_plain.txt); clientCode(std::move(plainStream)); // 注意std::move后plainStream不再可用 // 场景2使用加密的FileStream std::cout \n[Scenario 2] Encrypted File Stream: std::endl; auto encryptedStream std::make_uniqueEncryptionDecorator( std::make_uniqueFileStream(output_encrypted.txt) ); clientCode(std::move(encryptedStream)); // 场景3使用压缩且加密的FileStream (先压缩后加密) std::cout \n[Scenario 3] Compressed then Encrypted File Stream: std::endl; auto compressedEncryptedStream std::make_uniqueEncryptionDecorator( // 外层加密 std::make_uniqueCompressionDecorator( // 内层压缩 std::make_uniqueFileStream(output_compressed_encrypted.txt) // 核心文件 ) ); clientCode(std::move(compressedEncryptedStream)); // 场景4使用加密且压缩的FileStream (先加密后压缩) - 顺序不同结果不同 std::cout \n[Scenario 4] Encrypted then Compressed File Stream: std::endl; auto encryptedCompressedStream std::make_uniqueCompressionDecorator( // 外层压缩 std::make_uniqueEncryptionDecorator( // 内层加密 std::make_uniqueFileStream(output_encrypted_compressed.txt) // 核心文件 ) ); clientCode(std::move(encryptedCompressedStream)); return 0; }预期输出与解读 Decorator Pattern Demo in C [Scenario 1] Plain File Stream: [FileStream] Opening file: output_plain.txt --- Client is writing data --- [FileStream] Writing to file output_plain.txt: Hello, Decorator Pattern! --- Write operation finished --- [FileStream] Closing file: output_plain.txt [Scenario 2] Encrypted File Stream: [FileStream] Opening file: output_encrypted.txt --- Client is writing data --- [EncryptionDecorator] Encrypting data. [FileStream] Writing to file output_encrypted.txt: ENCRYPTED(Hello, Decorator Pattern!) --- Write operation finished --- [FileStream] Closing file: output_encrypted.txt [Scenario 3] Compressed then Encrypted File Stream: [FileStream] Opening file: output_compressed_encrypted.txt --- Client is writing data --- [EncryptionDecorator] Encrypting data. [CompressionDecorator] Compressing data. [FileStream] Writing to file output_compressed_encrypted.txt: COMPRESSED[ENCRYPTED(Hello, Decorator Pattern!)] --- Write operation finished --- [FileStream] Closing file: output_compressed_encrypted.txt [Scenario 4] Encrypted then Compressed File Stream: [FileStream] Opening file: output_encrypted_compressed.txt --- Client is writing data --- [CompressionDecorator] Compressing data. [EncryptionDecorator] Encrypting data. [FileStream] Writing to file output_encrypted_compressed.txt: ENCRYPTED(COMPRESSED[Hello, Decorator Pattern!]) --- Write operation finished --- [FileStream] Closing file: output_encrypted_compressed.txt从输出可以清晰看到透明性clientCode函数对传入的流是基础流还是被装饰过的流一无所知它一视同仁地调用write方法。动态组合我们轻松地组合出了“仅加密”、“先压缩后加密”、“先加密后压缩”等多种功能配置而无需创建任何新的类如EncryptedAndCompressedFileStream。执行顺序装饰器链的调用顺序是从外到内的。场景3中EncryptionDecorator在外层所以先执行加密再执行内层的压缩。场景4则相反。这印证了装饰顺序就是功能执行顺序。4. 装饰模式的优缺点与适用场景分析用了这么多代码演示我们来冷静地分析一下装饰模式的利弊以及它最适合在什么情况下出场。4.1 优势为什么选择它符合开闭原则这是最大的优点。你可以扩展对象的新行为创建新的ConcreteDecorator而无需修改现有的Component、ConcreteComponent或其他Decorator的代码。系统变得极具弹性。避免继承导致的类爆炸相比使用继承来为对象添加多种功能会产生N*M个组合子类装饰模式通过组合在运行时动态地添加功能类的数量是O(NM)线性增长大大简化了类层次结构。职责分离每个具体装饰器类只关注一个特定的附加功能如加密、压缩、日志符合单一职责原则。这使得每个装饰器都易于理解、实现和测试。动态与静态组合皆可你可以在运行时动态地、按需地添加或移除装饰器虽然C中由于所有权管理移除不如添加方便。也可以在编译时通过嵌套构造的方式静态组合出复杂的对象。替代多重继承在C中装饰模式提供了一种比多重继承更清晰、更灵活的方式来组合多个“横切关注点”cross-cutting concerns。4.2 劣势与陷阱什么情况下要慎用设计复杂化虽然最终使用起来灵活但模式本身引入了多层抽象接口、装饰器基类、具体装饰器对于简单系统来说这可能是一种过度设计反而让代码更难理解。装饰器栈的初始化与清理由于装饰器层层嵌套对象的构造和析构顺序需要仔细处理。使用智能指针如unique_ptr可以很好地管理生命周期但嵌套构造的语法make_uniqueA(make_uniqueB(...))在层数多时会显得冗长。可以考虑使用建造者模式Builder来简化复杂装饰链的创建过程。难以从装饰器外部识别对象类型因为客户端始终面对的是Component接口所以很难直接判断一个对象是否被特定装饰器装饰过或者它具体是什么类型。如果你需要基于对象的具体类型做条件判断装饰模式可能不太适合。装饰顺序的副作用如前所述装饰的顺序会影响最终行为。如果多个装饰器之间的功能存在依赖或冲突例如A装饰器必须在B装饰器之前执行那么就需要在文档或代码中明确约定增加了设计的复杂度。大量小对象每个装饰器都是一个独立的对象。如果装饰链很长会创建大量的小对象可能对性能内存分配、缓存局部性有轻微影响。在性能极度敏感的场合需要评估。4.3 经典适用场景根据我的经验装饰模式在以下场景中堪称“神器”I/O流处理这是教科书级的例子正如我们演示的。C标准库本身的设计如std::istream/std::ostream与std::ifstream/std::ofstream就蕴含了类似的思想。你可以轻松组合出带缓冲、带格式转换、带解压缩的流。GUI工具包中的视觉组件为窗口、按钮、文本框等基础控件动态添加滚动条、边框、阴影、拖拽等功能。每个功能都是一个独立的装饰器。中间件或过滤器链在网络框架或Web服务器中请求/响应处理管道pipeline非常适合用装饰模式实现。每个中间件如认证、日志、限流、数据压缩都是一个装饰器可以灵活组合。游戏开发中的角色/装备系统一个基础角色ConcreteComponent可以被武器、盔甲、饰品ConcreteDecorator装饰动态改变其攻击力、防御力、速度等属性。装备可以随时穿戴和卸下。日志记录系统基础日志器写入控制台。装饰器可以添加时间戳、日志级别过滤、写入文件、通过网络发送等功能。核心判断准则当你需要动态、透明、且以组合方式扩展对象的功能并且使用继承会导致类层次结构复杂不堪时就应该认真考虑装饰模式。5. 与其它模式的对比及实战进阶技巧理解了装饰模式本身我们还需要把它放在设计模式的“大家庭”里看看避免误用。同时分享几个我踩过坑才总结出来的进阶技巧。5.1 装饰模式 vs. 继承 vs. 组合这是最根本的抉择。继承is-a关系表达的是“是一个”的关系。EncryptedFileStream是一个FileStream并且是一种DataStream。它用于定义对象的本质类型。如果加密是文件流与生俱来、不可分割的本质特性那么用继承是合适的。但如果加密只是一个可选的、额外的功能继承就会让体系僵化。组合has-a关系装饰模式是组合的一种特殊而强大的应用。它表达的是“有一个”的关系。EncryptionDecorator有一个IDataStream并为其添加了加密行为。它用于动态扩展对象的行为而不是改变其本质。简单组合你也可以直接在FileStream里加一个EncryptionService成员变量。但这要求FileStream类本身知道加密的存在违反了开闭原则。装饰模式通过统一的Decorator接口将扩展功能与核心对象解耦。结论优先使用组合尤其是装饰模式这种结构化的组合而非继承来扩展对象的功能。这是面向对象设计的一个重要原则。5.2 装饰模式 vs. 适配器模式 vs. 代理模式这三个模式结构上有点相似都涉及包装一个对象但目的截然不同装饰模式Decorator增强功能。它不改变接口只为对象添加新的职责。装饰器和被装饰对象实现同一个接口。适配器模式Adapter转换接口。它改变对象的接口使其能与其他代码协作。适配器和被适配对象通常实现不同的接口。代理模式Proxy控制访问。它为一个对象提供一个替身或占位符以控制对这个对象的访问如延迟加载、访问控制、日志记录。代理和真实对象实现同一个接口但代理通常不增强功能而是控制访问过程。简单记忆装饰是“加料”适配是“转接头”代理是“秘书或门卫”。5.3 实战进阶技巧与避坑指南使用智能指针管理所有权正如示例中所用std::unique_ptr是装饰模式的绝配。它清晰地表达了装饰器“拥有”被装饰对象的所有权关系自动管理内存彻底杜绝了内存泄漏。如果需要在多个地方共享装饰链可以考虑std::shared_ptr但要小心循环引用。简化复杂装饰链的构建——引入建造者当装饰链很长时形如make_uniqueA(make_uniqueB(make_uniqueC(...)))的代码可读性很差。可以创建一个StreamBuilder类提供流畅接口Fluent Interface来简化构建auto stream StreamBuilder::beginWithFileStream(log.txt) .addDecoratorCompressionDecorator() .addDecoratorEncryptionDecorator() .build();装饰器是否需要访问Component的特定方法在标准装饰模式中Decorator和ConcreteComponent都通过共同的Component接口交互。但如果某个装饰器需要调用只有ConcreteComponent才有的特殊方法这就破坏了设计。这时需要重新审视设计要么将该方法提升到Component接口中如果合理要么考虑是否应该用其他模式如策略模式。性能考量与轻量级装饰器如果装饰器非常简单比如只是加个计数器每次调用都产生一层虚函数开销可能不划算。在性能热点路径上可以考虑使用基于策略的编译时装饰通过模板和CRTP但这会损失运行时的动态性。需要根据实际情况权衡。单元测试策略装饰器应该独立测试。测试EncryptionDecorator时可以传入一个MockDataStream模拟对象验证加密逻辑是否正确以及它是否正确调用了下游流的write方法。装饰器模式由于职责分离使得单元测试非常容易进行。小心“装饰链”过长虽然理论上可以无限装饰但过长的装饰链会降低调试和理解的难度。如果发现某个功能组合被频繁使用可以考虑创建一个“宏装饰器”Macro Decorator或直接创建一个新的具体组件来固化这个组合以简化使用。装饰模式是C工具箱中一把锋利而优雅的瑞士军刀。它通过组合和委托在保持接口一致性的前提下赋予了对象动态扩展能力的无限可能。掌握它意味着你在设计灵活、可维护的系统方面又迈进了一大步。下次当你想用继承来堆砌功能时不妨先停下来想一想“这里用装饰模式是不是更优雅”
1. 项目概述为什么我们需要装饰模式在C项目里摸爬滚打久了你肯定遇到过这种场景一个核心类功能稳定但需求方隔三差五就提新要求今天要加个日志明天要加个缓存后天又要支持性能监控。如果你每次都去修改这个核心类的源代码用不了多久这个类就会变得臃肿不堪各种功能耦合在一起牵一发而动全身维护起来简直是噩梦。更头疼的是有些功能组合是动态的、运行时才决定的比如这次请求需要“日志缓存”下次请求只需要“日志”用继承来实现这些功能组合会导致类爆炸比如LogCacheWidget,LogWidget,CacheWidget...。装饰模式Decorator Pattern就是为了优雅地解决这类“动态扩展对象功能”的问题而生的。它属于结构型设计模式其核心思想是在不改变原有对象结构的情况下动态地给一个对象添加一些额外的职责。就像给一个朴素的相框核心对象加上一层层不同的画框装饰器你可以选择加金边、加浮雕、加LED灯带这些装饰可以任意组合而且随时可以加上或取下完全不会损坏原来的相框。在C的语境下装饰模式通过组合和继承利用多态特性实现了功能的“即插即用”。它完美遵循了“开闭原则”对扩展开放对修改关闭让你能灵活应对变化的需求而不是通过修改既有的、稳定的代码。接下来我们就深入拆解这个模式的实现原理、在C中的典型写法以及那些只有踩过坑才知道的实战技巧。2. 核心思路与UML类图解析要理解装饰模式先得在脑子里建立起它的标准结构。我们可以把它想象成一个“俄罗斯套娃”或者“洋葱模型”。2.1 核心角色定义一个标准的装饰模式通常包含以下几个关键角色组件接口Component 这是所有对象的公共接口可以是抽象类或者纯虚接口。它定义了核心对象和装饰器对象共有的操作。在我们的相框比喻里这就是“可展示”这个行为。具体组件ConcreteComponent 这是我们要装饰的原始对象它实现了组件接口定义了核心的基础行为。比如那个最朴素的木头相框。装饰器基类Decorator 这是一个也实现了组件接口的抽象类。它的关键之处在于它内部持有一个指向组件接口的指针或引用。这个指针使得装饰器可以包裹一个组件对象无论是具体组件还是另一个装饰器。它通常会把所有操作委托给这个被包裹的对象但同时它也为子类定义了扩展功能的接口。具体装饰器ConcreteDecorator 继承自装饰器基类负责向组件添加新的职责。每个具体装饰器都会在调用被包裹对象的操作前后执行自己新增的逻辑。比如BorderDecorator负责加边框ShadowDecorator负责加阴影。2.2 标准UML类图与C映射虽然我们不能画图但可以用文字清晰地描述这个结构并对应到C代码Component (接口) | -- virtual void Operation() 0; | | 继承 | ConcreteComponent (具体组件) Decorator (装饰器基类) | | -- void Operation() override; -- Component* component_; // 关键组合一个组件 (实现核心逻辑) | -- void Operation() override { if (component_) component_-Operation(); } // 通常委托调用 | | 继承 | ConcreteDecoratorA ConcreteDecoratorB | | -- 添加新状态或行为 -- 添加新状态或行为 -- 在Operation中 -- 在Operation中 调用父类(Decorator)的 调用父类(Decorator)的 Operation并在其 Operation并在其 前后添加新逻辑。 前后添加新逻辑。C映射关键点Component: 通常是一个包含纯虚函数的抽象类class IComponent { public: virtual void execute() 0; }。组合关系:Decorator类中包含一个IComponent*或std::unique_ptrIComponent成员这是实现装饰能力的核心。委托调用:Decorator::execute()的实现中会调用component_-execute()。具体装饰器则先调用Decorator::execute()即委托给被装饰对象然后再执行自己的附加逻辑。多态链: 因为所有装饰器和具体组件都继承自IComponent所以你可以用ConcreteDecoratorA去包裹一个ConcreteDecoratorB而ConcreteDecoratorB又包裹着ConcreteComponent形成一条调用链。客户端代码只需要面对最外层的IComponent指针操作即可。这种结构的美妙之处在于装饰器对客户端是完全透明的。客户端只知道它在操作一个Component对象至于这个对象被层层包裹了多少功能客户端无需关心。3. C代码实现与逐行解读理论说再多不如一行代码来得实在。我们用一个经典的例子来演示一个数据输出流DataStream核心功能是写数据。我们需要动态地为其添加压缩CompressionDecorator和加密EncryptionDecorator功能。3.1 基础组件与具体组件实现首先定义我们的组件接口和最基本的具体组件。// Component.h - 组件接口 #ifndef COMPONENT_H #define COMPONENT_H #include string // 数据流接口定义核心操作 class IDataStream { public: virtual ~IDataStream() default; // 虚析构确保多态删除正确 // 核心操作写入数据 virtual void write(const std::string data) 0; // 可以添加read等其他操作此处为简化只写write }; #endif // COMPONENT_H// FileStream.h / FileStream.cpp - 具体组件文件流 #ifndef FILE_STREAM_H #define FILE_STREAM_H #include Component.h #include fstream #include iostream // 具体组件实现将数据写入文件 class FileStream : public IDataStream { public: explicit FileStream(const std::string filename) : filename_(filename) { // 构造函数中打开文件并非必须也可以在write时打开。这里演示简单初始化。 std::cout [FileStream] Opening file: filename_ std::endl; } ~FileStream() override { std::cout [FileStream] Closing file: filename_ std::endl; } void write(const std::string data) override { // 模拟写入文件的核心操作 std::cout [FileStream] Writing to file \ filename_ \: data std::endl; // 实际代码会是std::ofstream file(filename_, std::ios::app); file data; } private: std::string filename_; }; #endif // FILE_STREAM_H代码解读与注意事项接口设计IDataStream接口尽可能保持精简只定义最核心、最稳定的操作。这是设计模式成功的基础。虚析构函数基类的虚析构函数 (virtual ~IDataStream() default)至关重要。当通过基类指针删除派生类对象时它能确保调用正确的派生类析构函数避免内存泄漏。这是C多态编程的黄金法则之一。具体组件职责单一FileStream只关心一件事——把数据写到文件。它不应该知道任何关于加密或压缩的事情。3.2 装饰器基类实现这是装饰模式的核心枢纽它维护了指向被装饰对象的指针。// StreamDecorator.h - 装饰器基类 #ifndef STREAM_DECORATOR_H #define STREAM_DECORATOR_H #include Component.h #include memory // 使用智能指针管理生命周期 // 装饰器基类同样继承自IDataStream class StreamDecorator : public IDataStream { public: // 构造函数接收一个被装饰的流对象使用智能指针管理 explicit StreamDecorator(std::unique_ptrIDataStream stream) : stream_(std::move(stream)) { // std::move 转移所有权避免不必要的拷贝 } // 默认实现直接委托给被装饰的流对象 void write(const std::string data) override { if (stream_) { stream_-write(data); } } // 虚析构函数保证派生类对象能被正确销毁 virtual ~StreamDecorator() default; protected: // 保护成员允许派生类访问被装饰的流 std::unique_ptrIDataStream stream_; }; #endif // STREAM_DECORATOR_H关键点与实战技巧使用std::unique_ptr这是现代C管理资源所有权的推荐方式。它明确了StreamDecorator拥有stream_的所有权。当StreamDecorator对象销毁时stream_也会被自动销毁完美避免了原生指针可能带来的内存泄漏问题。std::move的使用在构造函数中我们使用std::move(stream)来转移传入的unique_ptr的所有权。这意味着调用者客户端在构造装饰器后就放弃了对原始流对象的所有权。这是装饰模式中对象“包裹”关系的直观体现。委托调用write方法的默认实现就是简单地调用stream_-write(data)。具体装饰器可以覆盖这个方法在调用前后添加自己的逻辑。3.3 具体装饰器实现现在我们来创建两个具体的装饰器加密装饰器和压缩装饰器。// EncryptionDecorator.h / .cpp #ifndef ENCRYPTION_DECORATOR_H #define ENCRYPTION_DECORATOR_H #include StreamDecorator.h #include string // 具体装饰器加密装饰器 class EncryptionDecorator : public StreamDecorator { public: // 继承基类构造函数 using StreamDecorator::StreamDecorator; void write(const std::string data) override { // 1. 执行加密操作此处为模拟 std::string encryptedData ENCRYPTED( data ); std::cout [EncryptionDecorator] Encrypting data. std::endl; // 2. 将加密后的数据传递给被装饰的流对象可能是基础流也可能是另一个装饰器 StreamDecorator::write(encryptedData); // 调用父类的write即委托调用 // 3. 可选加密后操作如记录日志 // std::cout [EncryptionDecorator] Encryption completed. std::endl; } }; #endif // ENCRYPTION_DECORATOR_H// CompressionDecorator.h / .cpp #ifndef COMPRESSION_DECORATOR_H #define COMPRESSION_DECORATOR_H #include StreamDecorator.h #include string // 具体装饰器压缩装饰器 class CompressionDecorator : public StreamDecorator { public: using StreamDecorator::StreamDecorator; void write(const std::string data) override { // 1. 执行压缩操作此处为模拟 // 假设压缩后数据变短用COMPRESSED标记 std::string compressedData COMPRESSED[ data ]; std::cout [CompressionDecorator] Compressing data. std::endl; // 2. 将压缩后的数据传递给被装饰的流对象 StreamDecorator::write(compressedData); } }; #endif // COMPRESSION_DECORATOR_H实现细节与逻辑执行顺序装饰器的逻辑是在委托调用StreamDecorator::write之前执行的。这意味着对于EncryptionDecorator(CompressionDecorator(FileStream))这样的链执行顺序是先加密然后加密后的数据进入压缩装饰器被压缩最后压缩的结果被写入文件。装饰的顺序决定了功能的执行顺序这一点需要根据业务逻辑仔细设计。using声明using StreamDecorator::StreamDecorator;这行代码继承了基类的构造函数这样EncryptionDecorator就可以直接用std::unique_ptrIDataStream来构造代码更简洁。模拟操作在实际项目中encryptedData和compressedData会是真正的加密/压缩算法结果。这里用字符串包裹来模拟便于理解执行流程。3.4 客户端调用与组合演示最后我们看看客户端如何像搭积木一样使用这些组件。// main.cpp #include iostream #include memory #include “FileStream.h” #include “EncryptionDecorator.h” #include “CompressionDecorator.h” void clientCode(std::unique_ptrIDataStream stream) { // 客户端代码只依赖于抽象的IDataStream接口 std::cout \n--- Client is writing data --- std::endl; stream-write(Hello, Decorator Pattern!); std::cout --- Write operation finished ---\n std::endl; } int main() { std::cout Decorator Pattern Demo in C std::endl; // 场景1使用最基础的FileStream std::cout \n[Scenario 1] Plain File Stream: std::endl; auto plainStream std::make_uniqueFileStream(output_plain.txt); clientCode(std::move(plainStream)); // 注意std::move后plainStream不再可用 // 场景2使用加密的FileStream std::cout \n[Scenario 2] Encrypted File Stream: std::endl; auto encryptedStream std::make_uniqueEncryptionDecorator( std::make_uniqueFileStream(output_encrypted.txt) ); clientCode(std::move(encryptedStream)); // 场景3使用压缩且加密的FileStream (先压缩后加密) std::cout \n[Scenario 3] Compressed then Encrypted File Stream: std::endl; auto compressedEncryptedStream std::make_uniqueEncryptionDecorator( // 外层加密 std::make_uniqueCompressionDecorator( // 内层压缩 std::make_uniqueFileStream(output_compressed_encrypted.txt) // 核心文件 ) ); clientCode(std::move(compressedEncryptedStream)); // 场景4使用加密且压缩的FileStream (先加密后压缩) - 顺序不同结果不同 std::cout \n[Scenario 4] Encrypted then Compressed File Stream: std::endl; auto encryptedCompressedStream std::make_uniqueCompressionDecorator( // 外层压缩 std::make_uniqueEncryptionDecorator( // 内层加密 std::make_uniqueFileStream(output_encrypted_compressed.txt) // 核心文件 ) ); clientCode(std::move(encryptedCompressedStream)); return 0; }预期输出与解读 Decorator Pattern Demo in C [Scenario 1] Plain File Stream: [FileStream] Opening file: output_plain.txt --- Client is writing data --- [FileStream] Writing to file output_plain.txt: Hello, Decorator Pattern! --- Write operation finished --- [FileStream] Closing file: output_plain.txt [Scenario 2] Encrypted File Stream: [FileStream] Opening file: output_encrypted.txt --- Client is writing data --- [EncryptionDecorator] Encrypting data. [FileStream] Writing to file output_encrypted.txt: ENCRYPTED(Hello, Decorator Pattern!) --- Write operation finished --- [FileStream] Closing file: output_encrypted.txt [Scenario 3] Compressed then Encrypted File Stream: [FileStream] Opening file: output_compressed_encrypted.txt --- Client is writing data --- [EncryptionDecorator] Encrypting data. [CompressionDecorator] Compressing data. [FileStream] Writing to file output_compressed_encrypted.txt: COMPRESSED[ENCRYPTED(Hello, Decorator Pattern!)] --- Write operation finished --- [FileStream] Closing file: output_compressed_encrypted.txt [Scenario 4] Encrypted then Compressed File Stream: [FileStream] Opening file: output_encrypted_compressed.txt --- Client is writing data --- [CompressionDecorator] Compressing data. [EncryptionDecorator] Encrypting data. [FileStream] Writing to file output_encrypted_compressed.txt: ENCRYPTED(COMPRESSED[Hello, Decorator Pattern!]) --- Write operation finished --- [FileStream] Closing file: output_encrypted_compressed.txt从输出可以清晰看到透明性clientCode函数对传入的流是基础流还是被装饰过的流一无所知它一视同仁地调用write方法。动态组合我们轻松地组合出了“仅加密”、“先压缩后加密”、“先加密后压缩”等多种功能配置而无需创建任何新的类如EncryptedAndCompressedFileStream。执行顺序装饰器链的调用顺序是从外到内的。场景3中EncryptionDecorator在外层所以先执行加密再执行内层的压缩。场景4则相反。这印证了装饰顺序就是功能执行顺序。4. 装饰模式的优缺点与适用场景分析用了这么多代码演示我们来冷静地分析一下装饰模式的利弊以及它最适合在什么情况下出场。4.1 优势为什么选择它符合开闭原则这是最大的优点。你可以扩展对象的新行为创建新的ConcreteDecorator而无需修改现有的Component、ConcreteComponent或其他Decorator的代码。系统变得极具弹性。避免继承导致的类爆炸相比使用继承来为对象添加多种功能会产生N*M个组合子类装饰模式通过组合在运行时动态地添加功能类的数量是O(NM)线性增长大大简化了类层次结构。职责分离每个具体装饰器类只关注一个特定的附加功能如加密、压缩、日志符合单一职责原则。这使得每个装饰器都易于理解、实现和测试。动态与静态组合皆可你可以在运行时动态地、按需地添加或移除装饰器虽然C中由于所有权管理移除不如添加方便。也可以在编译时通过嵌套构造的方式静态组合出复杂的对象。替代多重继承在C中装饰模式提供了一种比多重继承更清晰、更灵活的方式来组合多个“横切关注点”cross-cutting concerns。4.2 劣势与陷阱什么情况下要慎用设计复杂化虽然最终使用起来灵活但模式本身引入了多层抽象接口、装饰器基类、具体装饰器对于简单系统来说这可能是一种过度设计反而让代码更难理解。装饰器栈的初始化与清理由于装饰器层层嵌套对象的构造和析构顺序需要仔细处理。使用智能指针如unique_ptr可以很好地管理生命周期但嵌套构造的语法make_uniqueA(make_uniqueB(...))在层数多时会显得冗长。可以考虑使用建造者模式Builder来简化复杂装饰链的创建过程。难以从装饰器外部识别对象类型因为客户端始终面对的是Component接口所以很难直接判断一个对象是否被特定装饰器装饰过或者它具体是什么类型。如果你需要基于对象的具体类型做条件判断装饰模式可能不太适合。装饰顺序的副作用如前所述装饰的顺序会影响最终行为。如果多个装饰器之间的功能存在依赖或冲突例如A装饰器必须在B装饰器之前执行那么就需要在文档或代码中明确约定增加了设计的复杂度。大量小对象每个装饰器都是一个独立的对象。如果装饰链很长会创建大量的小对象可能对性能内存分配、缓存局部性有轻微影响。在性能极度敏感的场合需要评估。4.3 经典适用场景根据我的经验装饰模式在以下场景中堪称“神器”I/O流处理这是教科书级的例子正如我们演示的。C标准库本身的设计如std::istream/std::ostream与std::ifstream/std::ofstream就蕴含了类似的思想。你可以轻松组合出带缓冲、带格式转换、带解压缩的流。GUI工具包中的视觉组件为窗口、按钮、文本框等基础控件动态添加滚动条、边框、阴影、拖拽等功能。每个功能都是一个独立的装饰器。中间件或过滤器链在网络框架或Web服务器中请求/响应处理管道pipeline非常适合用装饰模式实现。每个中间件如认证、日志、限流、数据压缩都是一个装饰器可以灵活组合。游戏开发中的角色/装备系统一个基础角色ConcreteComponent可以被武器、盔甲、饰品ConcreteDecorator装饰动态改变其攻击力、防御力、速度等属性。装备可以随时穿戴和卸下。日志记录系统基础日志器写入控制台。装饰器可以添加时间戳、日志级别过滤、写入文件、通过网络发送等功能。核心判断准则当你需要动态、透明、且以组合方式扩展对象的功能并且使用继承会导致类层次结构复杂不堪时就应该认真考虑装饰模式。5. 与其它模式的对比及实战进阶技巧理解了装饰模式本身我们还需要把它放在设计模式的“大家庭”里看看避免误用。同时分享几个我踩过坑才总结出来的进阶技巧。5.1 装饰模式 vs. 继承 vs. 组合这是最根本的抉择。继承is-a关系表达的是“是一个”的关系。EncryptedFileStream是一个FileStream并且是一种DataStream。它用于定义对象的本质类型。如果加密是文件流与生俱来、不可分割的本质特性那么用继承是合适的。但如果加密只是一个可选的、额外的功能继承就会让体系僵化。组合has-a关系装饰模式是组合的一种特殊而强大的应用。它表达的是“有一个”的关系。EncryptionDecorator有一个IDataStream并为其添加了加密行为。它用于动态扩展对象的行为而不是改变其本质。简单组合你也可以直接在FileStream里加一个EncryptionService成员变量。但这要求FileStream类本身知道加密的存在违反了开闭原则。装饰模式通过统一的Decorator接口将扩展功能与核心对象解耦。结论优先使用组合尤其是装饰模式这种结构化的组合而非继承来扩展对象的功能。这是面向对象设计的一个重要原则。5.2 装饰模式 vs. 适配器模式 vs. 代理模式这三个模式结构上有点相似都涉及包装一个对象但目的截然不同装饰模式Decorator增强功能。它不改变接口只为对象添加新的职责。装饰器和被装饰对象实现同一个接口。适配器模式Adapter转换接口。它改变对象的接口使其能与其他代码协作。适配器和被适配对象通常实现不同的接口。代理模式Proxy控制访问。它为一个对象提供一个替身或占位符以控制对这个对象的访问如延迟加载、访问控制、日志记录。代理和真实对象实现同一个接口但代理通常不增强功能而是控制访问过程。简单记忆装饰是“加料”适配是“转接头”代理是“秘书或门卫”。5.3 实战进阶技巧与避坑指南使用智能指针管理所有权正如示例中所用std::unique_ptr是装饰模式的绝配。它清晰地表达了装饰器“拥有”被装饰对象的所有权关系自动管理内存彻底杜绝了内存泄漏。如果需要在多个地方共享装饰链可以考虑std::shared_ptr但要小心循环引用。简化复杂装饰链的构建——引入建造者当装饰链很长时形如make_uniqueA(make_uniqueB(make_uniqueC(...)))的代码可读性很差。可以创建一个StreamBuilder类提供流畅接口Fluent Interface来简化构建auto stream StreamBuilder::beginWithFileStream(log.txt) .addDecoratorCompressionDecorator() .addDecoratorEncryptionDecorator() .build();装饰器是否需要访问Component的特定方法在标准装饰模式中Decorator和ConcreteComponent都通过共同的Component接口交互。但如果某个装饰器需要调用只有ConcreteComponent才有的特殊方法这就破坏了设计。这时需要重新审视设计要么将该方法提升到Component接口中如果合理要么考虑是否应该用其他模式如策略模式。性能考量与轻量级装饰器如果装饰器非常简单比如只是加个计数器每次调用都产生一层虚函数开销可能不划算。在性能热点路径上可以考虑使用基于策略的编译时装饰通过模板和CRTP但这会损失运行时的动态性。需要根据实际情况权衡。单元测试策略装饰器应该独立测试。测试EncryptionDecorator时可以传入一个MockDataStream模拟对象验证加密逻辑是否正确以及它是否正确调用了下游流的write方法。装饰器模式由于职责分离使得单元测试非常容易进行。小心“装饰链”过长虽然理论上可以无限装饰但过长的装饰链会降低调试和理解的难度。如果发现某个功能组合被频繁使用可以考虑创建一个“宏装饰器”Macro Decorator或直接创建一个新的具体组件来固化这个组合以简化使用。装饰模式是C工具箱中一把锋利而优雅的瑞士军刀。它通过组合和委托在保持接口一致性的前提下赋予了对象动态扩展能力的无限可能。掌握它意味着你在设计灵活、可维护的系统方面又迈进了一大步。下次当你想用继承来堆砌功能时不妨先停下来想一想“这里用装饰模式是不是更优雅”
