C++策略模式实现：模板与多态选择详解

C++实现策略模式有两种核心思路：运行时多态和模板编译期多态。1. 运行时多态通过虚函数和基类指针实现动态绑定，支持运行时切换策略，适用于需要动态行为切换、频繁扩展策略或复杂生命周期管理的场景，但存在虚函数调用开销和对象体积增加的问题。2. 模板实现通过编译期确定策略类型，提供极致性能和类型安全，无运行时开销，但无法在运行时切换策略，适合策略固定且对性能要求极高的场景，可能带来代码膨胀和接口不明确的问题。选择应基于灵活性与性能的权衡，业务逻辑通常选运行时多态，底层库或高性能需求则选模板策略模式。

C++实现策略模式，核心无非两种思路：运行时多态和编译期模板。选择哪一个，取决于你对灵活性和性能的侧重，以及你对代码结构和复杂度的接受程度。运行时多态提供高度的灵活性和可扩展性，允许在程序运行期间动态切换行为；而模板则利用编译期特性，提供极致的性能优化和类型安全，但牺牲了部分运行时动态性。

解决方案

我们以一个简单的计算器为例，实现加法和减法两种策略。

1. 运行时多态实现

这种方式依赖于虚函数和基类指针，实现动态绑定。

#include 
#include  // For std::unique_ptr

// 抽象策略接口
class IOperation {
public:
    virtual ~IOperation() = default;
    virtual double execute(double a, double b) const = 0;
};

// 具体策略：加法
class AddOperation : public IOperation {
public:
    double execute(double a, double b) const override {
        return a + b;
    }
};

// 具体策略：减法
class SubtractOperation : public IOperation {
public:
    double execute(double a, double b) const override {
        return a - b;
    }
};

// 上下文类
class Calculator {
private:
    std::unique_ptr operation_;

public:
    // 构造函数注入策略
    explicit Calculator(std::unique_ptr op) : operation_(std::move(op)) {}

    // 运行时改变策略
    void setOperation(std::unique_ptr op) {
        operation_ = std::move(op);
    }

    double performOperation(double a, double b) const {
        if (!operation_) {
            // 实际项目中会抛出异常或返回错误码
            std::cerr << "Error: No operation set." << std::endl;
            return 0.0;
        }
        return operation_->execute(a, b);
    }
};

// 示例使用
// int main() {
//     Calculator calc(std::make_unique());
//     std::cout << "10 + 5 = " << calc.performOperation(10, 5) << std::endl; // 15
//
//     calc.setOperation(std::make_unique());
//     std::cout << "10 - 5 = " << calc.performOperation(10, 5) << std::endl; // 5
//
//     return 0;
// }

2. 模板实现（编译期多态）

这种方式不依赖虚函数，而是通过模板参数在编译时确定具体策略。

#include 

// 具体策略：加法（不需要继承任何接口）
class AddPolicy {
public:
    double execute(double a, double b) const {
        return a + b;
    }
};

// 具体策略：减法（不需要继承任何接口）
class SubtractPolicy {
public:
    double execute(double a, double b) const {
        return a - b;
    }
};

// 上下文类，模板化策略类型
template 
class TemplateCalculator {
private:
    OperationPolicy operation_; // 直接持有策略对象

public:
    // 策略在编译时确定，无法运行时改变（除非重新实例化整个Calculator）
    double performOperation(double a, double b) const {
        return operation_.execute(a, b);
    }
};

// 示例使用
// int main() {
//     TemplateCalculator addCalc;
//     std::cout << "10 + 5 = " << addCalc.performOperation(10, 5) << std::endl; // 15
//
//     TemplateCalculator subCalc;
//     std::cout << "10 - 5 = " << subCalc.performOperation(10, 5) << std::endl; // 5
//
//     // 注意：这里不能像运行时多态那样直接切换策略对象，
//     // 如果需要切换，得实例化一个新的TemplateCalculator对象。
//
//     return 0;
// }

运行时多态的策略模式：何时选择与实现细节

运行时多态的策略模式，在我看来，是经典的面向对象设计范式。它通过定义一个抽象接口（通常是抽象基类或纯虚函数），让不同的具体策略实现这个接口。核心在于使用基类指针或引用来操作具体策略对象，从而在运行时实现行为的动态切换。

何时选择？

• 运行时动态行为切换： 这是最主要的原因。如果你的程序需要在运行时根据用户输入、配置、或者其他环境因素来决定使用哪种算法或行为，那么运行时多态是你的不二选择。比如，一个游戏AI可能根据玩家距离选择“攻击策略”或“逃跑策略”；一个文件解析器可能根据文件类型选择不同的解析算法。
• 开放-封闭原则： 当你需要频繁地添加新的策略，而又不想修改现有代码（特别是上下文类）时，运行时多态表现出色。你只需要创建新的策略类，实现那个共同的接口，然后就可以在系统中“即插即用”了。这对于大型、持续演进的系统至关重要。
• 策略的生命周期管理： 当策略对象需要复杂的生命周期管理，或者它们是重量级资源时，通过智能指针（如std::unique_ptr或std::shared_ptr）管理基类指针，可以清晰地控制对象的创建和销毁。

实现细节：

实现运行时多态的关键是virtual关键字和虚函数表（vtable）。当通过基类指针调用虚函数时，编译器会通过vtable在运行时查找正确的函数地址。这意味着：

1. 开销： 每次虚函数调用都会有一次间接寻址的开销（查找vtable），这比直接函数调用略慢。对于性能极致敏感的场景，这可能是个考量点。
2. 对象大小： 含有虚函数的类会额外增加一个虚指针（vptr）的开销，通常是8字节（64位系统）。
3. 内存管理： 由于上下文类通常持有指向抽象基类的指针，你需要考虑这些策略对象的生命周期。std::unique_ptr是管理独占所有权的推荐方式，它能确保在上下文对象销毁时，其持有的策略对象也会被正确销毁，避免内存泄漏。如果策略需要共享，std::shared_ptr也是一个选项。

我个人觉得，对于大多数业务逻辑和应用层面的设计，运行时多态带来的灵活性和可维护性远超那一点点性能开销。尤其是在团队协作中，它能让不同模块的开发者在不影响彼此核心代码的情况下，独立地扩展功能。

模板实现策略模式：编译期优势与潜在局限

模板实现的策略模式，有时也被称为“策略作为策略参数”或者“基于策略的类设计”。它利用C++的模板机制，在编译时将具体的策略类型绑定到上下文类上。

编译期优势：

• 极致性能： 这是模板策略模式最吸引人的地方。由于策略是在编译时确定的，编译器可以进行静态绑定，甚至可能将策略函数内联到调用点，彻底消除了虚函数调用的运行时开销。对于性能敏感的算法、库或底层系统，这简直是福音。
• 类型安全： 编译器在编译阶段就能检查策略接口是否符合要求（鸭子类型，即只要有对应的方法即可），而不是等到运行时才发现问题。这有助于早期发现错误。
• 无额外运行时开销： 没有vptr，没有vtable查找，上下文对象的大小更小，执行速度更快。

潜在局限：

• 运行时无法切换策略： 这是最大的限制。一旦TemplateCalculator被实例化，它的策略就是AddPolicy，你无法在运行时把它变成SubtractPolicy。如果需要切换，你必须创建一个新的TemplateCalculator实例。这对于需要动态行为的场景是不可接受的。
• 代码膨胀（Code Bloat）： 如果你有许多不同的策略类型，并且为每种策略类型都实例化了上下文类，那么编译器可能会生成多份相似的代码副本，导致最终的可执行文件体积增大。不过，现代编译器在优化方面做得很好，通常能减少这种影响。
• 接口不明确： 相比于运行时多态有明确的IOperation接口，模板策略模式没有强制的继承关系。策略类只需要提供上下文类所需的方法即可（鸭子类型）。这在某些情况下可能导致接口契约不那么直观，但同时它也更灵活，策略类可以不为特定接口而设计。
• 编译时间： 大量模板的使用可能会增加编译时间，尤其是在大型项目中。

我个人的经验是，如果你在构建一个高性能的库，或者你的策略集合在设计时就是固定且已知的，并且对性能有极高的要求，那么模板策略模式绝对值得考虑。它能让你写出既灵活又快速的代码。但如果需求经常变动，或者你更看重运行时动态性，那还是得三思。

两种实现方式的取舍与实际应用场景

选择运行时多态还是模板实现策略模式，核心在于对“灵活性”和“性能”的权衡。这两种方式各有千秋，没有绝对的优劣，只有更适合特定场景的选择。

取舍对比：

实际应用场景：

• 选择运行时多态的场景：

  • UI事件处理： 不同的按钮点击可能触发不同的行为，这些行为在运行时确定。
  • 日志系统： 可能需要动态切换日志输出目的地（控制台、文件、网络），或不同的日志格式。
  • 网络协议解析： 根据接收到的数据包类型，动态选择不同的解析策略。
  • 文件系统操作： 针对不同类型的文件（文本、二进制、压缩文件）采用不同的读写或处理策略。
  • 插件系统： 允许用户在运行时加载新的功能模块，这些模块作为策略被注入。
  • 业务规则引擎： 根据特定条件动态应用不同的业务规则。

• 选择模板实现策略模式的场景：

  • 高性能数值计算库： 例如，不同的矩阵乘法算法，在编译时确定最佳策略以消除运行时开销。
  • 自定义容器或算法： 如std::vector允许自定义分配器（allocator）策略，std::sort允许自定义比较策略。
  • 策略模式作为“政策（Policy）”： 在库设计中，允许用户通过模板参数注入自定义行为，形成高度可配置的组件。例如，C++标准库中的std::basic_string通过模板参数CharT和Traits来定制字符类型和字符操作策略。
  • 编译期优化： 如果你确切知道在编译时就能确定所有可能的策略，并且对性能有极致追求，模板是理想选择。

我个人的看法是，对于大多数业务应用开发，运行时多态是更“安全”和“通用”的选择。它提供了足够的灵活性，并且其性能开销在现代硬件上通常可以忽略不计。但如果你正在开发一个底层库、一个游戏引擎的核心组件，或者任何对性能有毫秒级甚至纳秒级要求的系统，那么模板策略模式的优势就会凸显出来。它能让你压榨出C++语言的最后一丝性能。最终，这两种方式并非互斥，它们可以根据项目的具体需求和设计哲学，在不同模块中和谐共存。