策略模式通过多态实现算法的运行时替换，C++中利用虚函数机制使Context类通过抽象接口调用具体策略，实现解耦；结合工厂模式可进一步解耦对象创建，提升系统灵活性与可维护性。
C++利用多态性，主要是通过虚函数（
virtualfunctions）机制，来实现策略模式的核心思想——在运行时选择不同的算法行为。它允许你定义一系列算法，将每一个算法封装起来，并使它们可以互相替换，从而让算法的变化独立于使用算法的客户端。简单来说，就是把“做什么”和“怎么做”分离开来，让“怎么做”的部分可以灵活地插拔。
解决方案
在C++中实现策略模式，我们通常会定义一个抽象基类或接口来声明所有策略共有的操作，然后为每一种具体的算法实现一个派生类。一个“上下文”（Context）类会持有一个指向这个抽象策略接口的指针或引用，并通过它来调用具体的策略实现。
我们来构建一个简单的计算器场景，它需要支持多种运算（加、减、乘）。
首先，定义一个抽象的策略接口：
立即学习“C++免费学习笔记（深入）”；
// 策略接口：定义所有具体策略必须实现的操作
class ICalculationStrategy {
public:
virtual ~ICalculationStrategy() = default; // 虚析构函数很重要，确保正确释放内存
virtual double calculate(double a, double b) const = 0; // 纯虚函数，要求派生类实现
};接着，实现具体的策略类：
// 具体策略A：加法运算
class AddStrategy : public ICalculationStrategy {
public:
double calculate(double a, double b) const override {
return a + b;
}
};
// 具体策略B：减法运算
class SubtractStrategy : public ICalculationStrategy {
public:
double calculate(double a, double b) const override {
return a - b;
}
};
// 具体策略C：乘法运算
class MultiplyStrategy : public ICalculationStrategy {
public:
double calculate(double a, double b) const override {
return a * b;
}
};最后，构建一个上下文类，它负责持有并执行策略：
// 上下文类：持有策略对象，并委托其执行操作 #include// 为了使用智能指针 class CalculatorContext { private: std::unique_ptr strategy_; // 使用智能指针管理策略对象的生命周期 public: // 构造函数：初始化时传入一个具体策略 explicit CalculatorContext(std::unique_ptr strategy) : strategy_(std::move(strategy)) {} // 运行时改变策略 void setStrategy(std::unique_ptr strategy) { strategy_ = std::move(strategy); } // 执行策略定义的操作 double executeCalculation(double a, double b) const { if (!strategy_) { // 处理策略未设置的情况，或者抛出异常 // 这里为了简洁，我们假设策略总是有效的 return 0.0; } return strategy_->calculate(a, b); } };
在客户端代码中，我们可以这样使用它：
#include// ... 上述类定义 ... int main() { // 使用加法策略 CalculatorContext calculator(std::make_unique ()); std::cout << "10 + 5 = " << calculator.executeCalculation(10, 5) << std::endl; // 输出 15 // 运行时切换到减法策略 calculator.setStrategy(std::make_unique ()); std::cout << "10 - 5 = " << calculator.executeCalculation(10, 5) << std::endl; // 输出 5 // 运行时切换到乘法策略 calculator.setStrategy(std::make_unique ()); std::cout << "10 * 5 = " << calculator.executeCalculation(10, 5) << std::endl; // 输出 50 // 如果需要，可以随时添加新的运算策略，而无需修改CalculatorContext类 return 0; }
通过这种方式，
CalculatorContext类完全不知道它正在执行的是加法、减法还是乘法，它只知道调用
strategy_->calculate()。这就是多态带来的解耦和灵活性。
为什么策略模式需要多态？或者说，多态在策略模式中扮演了什么角色？
要我说，多态性在策略模式中简直是“灵魂”般的存在。没有多态，策略模式就失去了其核心价值。它的作用主要体现在几个方面：
首先，实现了算法的运行时可替换性。策略模式的精髓在于，我们可以在程序运行时，根据需要动态地切换算法。C++中的虚函数机制正是实现这一点的基石。当
CalculatorContext持有一个
ICalculationStrategy*指针时，它可以在不知道具体类型的情况下，通过这个指针调用
calculate()方法。编译器和运行时系统会确保调用到实际指向对象的正确实现（例如，如果指针指向
AddStrategy对象，就会调用
AddStrategy::calculate）。如果没有虚函数，
Context类就只能调用基类的方法，或者需要通过大量的
if-else或
switch-case语句来判断具体类型并调用相应的方法，这会使得代码变得僵硬、难以维护和扩展。
其次，达成了客户端与算法实现的高度解耦。想象一下，如果我们的
CalculatorContext不得不直接知道
AddStrategy、
SubtractStrategy等具体类，那么每当我们新增一种运算（比如除法），我们就得回去修改
CalculatorContext的代码。这显然违背了“开闭原则”（对扩展开放，对修改关闭）。多态通过抽象接口将具体实现细节隐藏起来，
CalculatorContext只需要依赖于
ICalculationStrategy这个抽象接口，而无需关心具体的算法是如何实现的。这种解耦使得系统更加健壮，也更容易应对需求变化。
最后，提升了代码的灵活性和可扩展性。当我们需要添加新的策略时，只需要创建一个新的具体策略类，实现
ICalculationStrategy接口即可。
Context类和现有的策略类都不需要改动。这大大降低了系统维护的成本，也让代码结构更加清晰，符合“单一职责原则”（每个类只负责一个职责）。在我看来，这种“不碰旧代码，只写新代码”的扩展方式，是每一个开发者都梦寐以求的。多态在这里提供了一个统一的入口，让所有新旧策略都能通过这个入口被无缝集成。
在C++中实现策略模式时，有哪些常见的陷阱或需要注意的设计考量？
实践中，策略模式在C++里虽然强大，但也有不少细节需要我们细心打磨，不然就可能掉进坑里。
一个最常见的，也是最让人头疼的问题，就是策略对象的生命周期管理。在我的示例中，我用了
std::unique_ptr来管理
strategy_，这是一种非常推荐的做法。如果用裸指针，那么谁来负责
new，谁来负责
delete？是
Context创建并销毁策略，还是外部创建并传递给
Context，然后
Context只负责使用？如果
Context负责销毁，那么它需要知道何时销毁，以及如何正确销毁（特别是当策略是通过多态创建时，虚析构函数是必不可少的）。如果外部创建并销毁，那么
Context就不能持有所有权，可能只持有一个
const引用或
std::weak_ptr，这又引入了外部对象存活时间的问题。
std::unique_ptr在这里提供了一种清晰的所有权语义：当
Context对象销毁时，它所持有的策略对象也会被自动销毁。如果策略是共享的，
std::shared_ptr也是一个不错的选择。
另一个需要考虑的是策略的状态。我的
AddStrategy、
SubtractStrategy都是无状态的，它们只执行计算，不保存任何信息。这样的策略通常可以被多个
Context对象共享，甚至可以设计成单例模式。但如果策略是有状态的，比如一个需要维护历史记录的加密策略，那么每个
Context可能就需要拥有一个独立的策略实例，或者在策略中引入额外的机制来管理其状态。这会增加设计的复杂性，需要仔细权衡。通常，我们倾向于设计无状态的策略，因为它们更易于理解和复用。
还有就是策略接口的设计。
ICalculationStrategy的
calculate方法只接受两个
double参数，返回一个
double。这非常简洁。但在实际应用中，策略方法可能需要访问
Context的一些内部数据，或者需要更复杂的参数。这时候，你可以考虑将
Context的引用或指针作为参数传递给策略方法，或者设计一个更丰富的参数结构体。不过，这样做可能会让策略与
Context之间的耦合度略微上升，需要找到一个平衡点。过于宽泛的接口可能导致策略类承担了过多的责任，而过于狭窄的接口可能又不够用。
最后，不能忽视的是性能开销。虚函数调用确实会引入轻微的运行时开销（vtable查找）。对于大多数业务逻辑而言，这种开销是微不足道的，可以忽略不计。但在对性能极度敏感的场景，比如高性能计算或嵌入式系统，这种开销可能就需要被考虑进去。不过，通常情况下，策略模式带来的设计优势远超这点性能损失。
策略模式与工厂模式、模板方法模式等其他设计模式有何异同，它们如何协同工作？
理解设计模式，很多时候在于理解它们之间的边界与协作。策略模式与其他模式的关系，可以说是一种“分工与合作”的体现。
先说策略模式与模板方法模式。它们都关注算法，但侧重点和实现方式截然不同。
-
策略模式（Strategy Pattern）：它关注的是算法的替换。它通过对象组合（Context持有Strategy对象）和多态，让客户端可以在运行时选择不同的算法。算法是完全独立的，Context只负责“委托”执行。我的计算器例子就是典型的策略模式，
CalculatorContext
可以随时换上加法、减法或乘法策略。 - 模板方法模式（Template Method Pattern）：它关注的是算法骨架的固定与部分步骤的定制。它通过继承，在抽象基类中定义一个算法的骨架（即“模板方法”），其中某些步骤是抽象的，留给派生类去实现。派生类不能改变算法的整体结构，只能定制其中的某些细节。比如，一个“文件处理”的模板方法可能定义了“打开文件 -> 读取数据 -> 处理数据 -> 关闭文件”的骨架，其中“处理数据”是抽象的，具体子类可以实现不同的处理逻辑（加密、压缩等）。 它们的主要区别在于：策略模式通过组合实现运行时行为的替换，算法之间是平等的；模板方法通过继承实现算法骨架的复用和部分步骤的定制，子类在父类的框架内工作。
再看策略模式与工厂模式。这两者经常被一起使用，简直是天作之合。
工厂模式（Factory Pattern）：它关注的是对象的创建。它提供一个创建对象的接口，但让子类决定实例化哪一个类。工厂模式将对象的创建逻辑封装起来，使得客户端无需知道具体类的名称。例如，一个
OperationFactory
可以根据传入的字符串（如"add"、"subtract"）来创建并返回一个AddStrategy
或SubtractStrategy
的实例。-
协同工作：一个常见的场景是，客户端根据某种条件（比如用户输入、配置文件设置）需要选择一个具体的策略。这时候，我们可以用一个工厂来根据这些条件创建具体的策略对象，然后将这个创建好的策略对象注入到
Context
中。这样，客户端既不需要直接知道具体的策略类名，也不需要自己去new
这些对象，使得整个系统更加灵活和可维护。例如：// 假设有一个工厂类 class StrategyFactory { public: static std::unique_ptrcreateStrategy(const std::string& type) { if (type == "add") { return std::make_unique (); } else if (type == "subtract") { return std::make_unique (); } else if (type == "multiply") { return std::make_unique (); } // 错误处理 return nullptr; } }; // 在main函数中 // ... std::string operationType = "add"; // 假设从用户输入或配置中获取 auto strategy = StrategyFactory::createStrategy(operationType); if (strategy) { CalculatorContext calculator(std::move(strategy)); std::cout << "Using " << operationType << ": 10 ? 5 = " << calculator.executeCalculation(10, 5) << std::endl; } // ... 通过这种组合，我们不仅实现了算法的运行时可替换，也实现了策略对象创建过程的解耦，让整个系统更加模块化。策略模式和工厂模式是设计模式中非常实用且常见的组合，能够有效地提升代码的灵活性和可维护性。
