C++实现装饰器模式动态增强类功能 _ 包装类与虚函数组合设计【源码】

在C++里实现装饰器模式，核心思路其实很清晰：它不在于追求Python那种@decorator的语法糖，而在于构建一种可组合、非侵入的增强机制。简单来说，就是通过一个包装类，持有一个指向相同抽象接口的指针，将调用转发给它，并在转发前后注入自己的逻辑。

一个关键的设计准则是：必须用std::unique_ptr来管理所有权，避免使用裸指针，并充分利用移动语义来传递控制权，这样才能确保资源管理的安全性和明确性。

为什么不能直接继承并重写？

直接派生子类去覆盖虚函数，听起来简单，但它彻底破坏了装饰器模式最宝贵的“动态叠加”能力。举个例子，如果你既需要日志功能（LoggingDecorator），又需要重试功能（RetryDecorator），靠硬编码继承链（比如创建一个RetryLoggingWidget）会带来两个大问题：一是组合数量会爆炸式增长，二是无法在运行时灵活地装配或切换这些功能。

因此，可行的路径是：让所有装饰器和被装饰的核心对象，都实现同一个纯虚基类接口（例如Widget）。装饰器内部持有一个指向该接口的指针（或智能指针），并将收到的调用请求转发给它——这就是“包装类”的本质。

• 首先，定义一个纯虚基类（如Widget），所有需要被装饰或增强的行为都通过其虚函数暴露出来。
• 装饰器的构造函数接收一个std::unique_ptr或Widget&，务必避免使用裸指针，以防生命周期管理失控。
• 装饰器自身也必须继承自Widget，这样它才能被另一个装饰器继续包装，从而形成链式调用。
• 需要警惕的是，绝不要在装饰器的公开接口中，暴露被包装对象的原始具体类型。一旦暴露，下游代码就可能绕过装饰逻辑直接操作底层对象，破坏了封装。

如何避免虚函数调用开销影响性能？

虚函数调用本身的开销其实很小，只是一次间接跳转。但是，如果装饰链过长（比如超过5层），而被装饰的函数本身又极其轻量（例如仅仅返回一个整数），那么这层层转发的累积开销就可能成为性能瓶颈。这时候就需要权衡：

• 编译期组合优先：如果装饰行为是固定的、种类有限的，可以考虑使用模板策略等编译期技术来替代运行期的装饰器，从而完全消除运行时开销。
• 内联提示：如果必须动态组合，可以对装饰器内部的非虚转发函数使用编译器的内联提示，比如GCC/Clang的[[gnu::always_inline]]或MSVC的__forceinline。注意，这个属性只能加在具体的成员函数定义上，不能加在虚函数声明上。
• 避免重复计算：确保装饰器中的逻辑是高效的。例如，不要在每次调用时都去解析配置或计算固定值，而应该在构造函数中提前计算并缓存起来。
• 使用final修饰符：对于装饰链末端的、不再需要被继承的装饰器类，可以用final关键字修饰。这能给编译器提供明确的优化信息，有助于去虚拟化（devirtualization）。

std::shared_ptr 还是 std::unique_ptr？选哪个传给装饰器？

这取决于你设计的所有权模型。在大多数场景下，使用std::unique_ptr是更安全、意图更清晰的选择：

• std::unique_ptr：它明确表达了“装饰器完全拥有被包装对象”的语义。所有权随着std::move转移，生命周期由装饰器管理，从根本上避免了悬空指针的问题。
• std::shared_ptr：适用于多个装饰器需要共享同一个底层对象的情况（比如，一个日志装饰器和一个监控装饰器包装的是同一个网络客户端实例）。但使用时要特别警惕循环引用——如果装饰器A持有B，B又持有A，就会导致内存泄漏。这时需要用std::weak_ptr来打破循环。
• 绝对避免裸指针或引用：尽量不要将裸指针（Widget*）或引用（Widget&）传递给装饰器的构造函数，除非你能百分之百保证被包装对象的生存期长于所有装饰器实例。
• 栈对象的特殊情况：如果底层对象是在栈上创建的（例如ConsoleWidget console;），那么装饰器只能通过引用的方式持有它。但必须加上清晰的注释，警告使用者：“此装饰器的有效性依赖于console对象的生命周期，不可单独存在。”

一个最小可运行的装饰链示例

下面的代码展示了一个典型的三层装饰链：原始功能 → 添加日志 → 添加重试。注意看，每个类都只关心自己那一层的职责，对上下层的具体实现一无所知：

class Widget {
public:
    virtual ~Widget() = default;
    virtual void render() = 0;
};

class ConsoleWidget : public Widget {
public:
    void render() override { std::cout << "draw on console\n"; }
};

class LoggingDecorator : public Widget {
    std::unique_ptr wrapped_;
public:
    explicit LoggingDecorator(std::unique_ptr w) : wrapped_(std::move(w)) {}
    void render() override {
        std::cout << "[LOG] before\n";
        wrapped_->render();
        std::cout << "[LOG] after\n";
    }
};

class RetryDecorator : public Widget {
    std::unique_ptr wrapped_;
    int max_retries_ = 2;
public:
    explicit RetryDecorator(std::unique_ptr w) : wrapped_(std::move(w)) {}
    void render() override {
        for (int i = 0; i <= max_retries_; ++i) {
            try {
                wrapped_->render();
                return;
            } catch (...) {
                if (i == max_retries_) throw;
            }
        }
    }
};

// 使用方式：
auto widget = std::make_unique();
widget = std::make_unique(std::move(widget));
widget = std::make_unique(std::move(widget));
widget->render(); // 执行时，会依次输出日志并包含重试行为

这段代码里，最容易忽略但又至关重要的一点是移动语义的连贯性。每一层装饰器都通过std::move来接收并转移std::unique_ptr的所有权。如果漏掉了任何一个std::move，编译器就会报错，因为unique_ptr不可拷贝。这看似麻烦，其实是件好事，它强制你在编码时就必须清晰地处理好所有权问题。