策略模式通过将算法封装为独立的可互换对象，使上下文在运行时动态切换行为，从而实现“做什么”与“怎么做”的分离，提升灵活性与可维护性。
C++中策略模式的核心在于允许一个对象在运行时改变其行为。它通过将一系列算法封装成独立的、可互换的对象来实现这一点，从而避免了在客户端代码中硬编码算法选择，极大地提升了系统的灵活性和可维护性。简单来说，就是“做什么”和“怎么做”的分离。
解决方案
实现C++策略模式，我们通常会定义一个抽象的策略接口（或抽象基类），然后为每种具体的算法实现一个具体的策略类。最后，一个上下文（Context）类会持有一个策略对象的引用，并委托该策略对象来执行具体的算法。这样，客户端只需要与上下文交互，并通过上下文在运行时切换不同的策略，而无需关心具体算法的实现细节。
让我们通过一个简单的例子来理解。假设我们需要一个计算器，它能执行加法、减法、乘法等多种运算，并且我们希望能在程序运行时切换这些运算方式。
#include #include // For std::unique_ptr// 1. 抽象策略接口 (Abstract Strategy)// 定义所有具体策略都必须实现的操作class OperationStrategy {public: virtual ~OperationStrategy() = default; // 虚析构函数确保正确释放资源 virtual int execute(int a, int b) const = 0;};// 2. 具体策略类 (Concrete Strategies)// 实现抽象策略接口，提供具体的算法class AddOperation : public OperationStrategy {public: int execute(int a, int b) const override { return a + b; }};class SubtractOperation : public OperationStrategy {public: int execute(int a, int b) const override { return a - b; }};class MultiplyOperation : public OperationStrategy {public: int execute(int a, int b) const override { return a * b; }};// 3. 上下文类 (Context)// 持有一个策略对象的引用，并提供接口供客户端设置和使用策略class Calculator {private: std::unique_ptr strategy; // 使用智能指针管理策略对象的生命周期public: // 构造函数允许初始化时设置策略 explicit Calculator(std::unique_ptr initialStrategy) : strategy(std::move(initialStrategy)) {} // 运行时改变策略的方法 void setStrategy(std::unique_ptr newStrategy) { strategy = std::move(newStrategy); } // 执行当前策略定义的操作 int performOperation(int a, int b) const { if (!strategy) { std::cerr << "Error: No strategy set!" <execute(a, b); }};// 客户端代码示例int main() { // 初始化计算器，默认使用加法策略 Calculator calculator(std::make_unique()); std::cout << "Using Add Strategy: 10 + 5 = " << calculator.performOperation(10, 5) << std::endl; // 运行时切换到减法策略 calculator.setStrategy(std::make_unique()); std::cout << "Switching to Subtract Strategy: 10 - 5 = " << calculator.performOperation(10, 5) << std::endl; // 运行时切换到乘法策略 calculator.setStrategy(std::make_unique()); std::cout << "Switching to Multiply Strategy: 10 * 5 = " << calculator.performOperation(10, 5) << std::endl; // 尝试在没有策略的情况下执行操作 (如果允许构造无策略的Calculator) // Calculator emptyCalc; // 这需要一个默认构造函数，且要处理strategy为nullptr的情况 // std::cout << emptyCalc.performOperation(10, 5) << std::endl; return 0;}
这段代码清晰地展示了策略模式的结构。
OperationStrategy
定义了行为的契约，
AddOperation
、
SubtractOperation
、
MultiplyOperation
是具体的实现，而
Calculator
则是上下文，它将具体的行为委托给当前的策略对象。客户端代码通过
setStrategy
方法，轻松地在运行时改变
Calculator
的行为，这正是策略模式的魅力所在。我个人觉得，这种模式在处理复杂业务逻辑中，那些需要根据不同条件执行不同计算或流程的场景下，简直是救命稻草。它让代码从一堆嵌套的
if-else
或
switch
语句中解脱出来，变得清爽多了。
立即学习“C++免费学习笔记（深入）”；
C++策略模式如何提升代码的灵活性与可维护性？
策略模式在C++项目中提升代码的灵活性与可维护性，其核心在于它有效地解耦了算法的使用者（上下文）与算法本身（具体策略）。这种解耦带来了一系列显著的好处，远不止是避免了
switch
语句那么简单。
从灵活性的角度来看，策略模式让系统能够轻松地在运行时切换不同的算法。想象一下，一个数据处理系统需要根据用户选择或外部配置来应用不同的排序算法。如果没有策略模式，你可能需要在处理逻辑中写一大堆条件判断，这不仅代码臃肿，而且每次新增一种排序方式，都得修改核心处理逻辑，这简直是噩梦。而有了策略模式，你只需实现一个新的
SortStrategy
类，然后在运行时将其注入到上下文中即可，无需改动任何现有代码。这完美地遵循了“开闭原则”（Open/Closed Principle）：对扩展开放，对修改关闭。这种能力在面对需求频繁变更的系统时显得尤为宝贵。
至于可维护性，策略模式的贡献同样巨大。它将每个算法封装在独立的类中，使得每个算法的实现都高度内聚。这意味着，当你需要修改某个算法的内部逻辑时，你只需要关注对应的策略类，而不会影响到系统的其他部分。这种隔离性极大地降低了修改代码可能引入的风险。同时，由于每个策略都是独立的单元，它们的测试也变得更加简单和直接。你可以为每个具体的策略编写独立的单元测试，确保其正确性，而无需启动整个上下文环境。我个人在维护一些老旧系统时，最头疼的就是那种一个函数包罗万象、各种逻辑混杂在一起的代码。策略模式就像是给这些混乱的代码画了一条清晰的界线，让每个部分各司其职，维护起来自然轻松很多。
在C++中实现策略模式时，常见的陷阱与最佳实践有哪些？
虽然策略模式强大，但实现时也并非没有坑。一些常见的陷阱和对应的最佳实践值得我们深入探讨，毕竟“知其然”还要“知其所以然”。
一个首要的陷阱是策略对象的生命周期管理。在C++中，尤其当涉及到多态和指针时，内存管理总是需要格外小心。如果上下文类持有的是原始指针（raw pointer）到策略对象，那么谁来负责创建和销毁这个策略对象就成了一个问题。如果上下文自己
new
了一个策略，那么它也应该负责
delete
。如果策略是从外部传入的，那么上下文是否拥有其所有权？不明确的生命周期管理很容易导致内存泄漏或悬空指针。
最佳实践是使用C++的智能指针，特别是
std::unique_ptr
或
std::shared_ptr
。在我们的例子中，
Calculator
类使用了
std::unique_ptr strategy;
，这明确表示
Calculator
独占其策略对象的所有权。当
Calculator
对象被销毁时，它所持有的
unique_ptr
会自动销毁其指向的策略对象，避免了内存泄漏。如果多个上下文可能共享同一个策略实例（例如，一个无状态的策略），那么
std::shared_ptr
会是更好的选择，它通过引用计数来管理共享对象的生命周期。选择哪种智能指针取决于具体的设计意图和策略对象的特性。
另一个陷阱是过度设计。策略模式确实很优雅，但并非所有场景都适用。对于只有两三种简单行为且未来变化不大的情况，一个简单的
if-else
或
switch
语句可能更直接、代码量更少。强行引入策略模式反而会增加不必要的类和接口，使代码变得复杂。我见过一些项目，为了“模式化”而模式化，结果把简单问题搞复杂了。
最佳实践是权衡利弊，只在真正需要运行时行为切换、或者预期未来会有大量新算法加入的场景下使用策略模式。如果算法逻辑非常简单且稳定，那么保持代码的简洁性可能更重要。
此外，策略接口的设计也至关重要。如果接口定义得过于宽泛或过于狭窄，都会带来问题。过于宽泛可能导致具体策略类需要实现很多与自身无关的方法；过于狭窄可能无法满足所有具体策略的需求。
最佳实践是保持策略接口的单一职责原则，使其只包含与核心算法行为相关的方法。同时，思考策略是否需要访问上下文的状态。如果策略需要上下文的数据，通常的做法是在策略的执行方法中将所需数据作为参数传入，而不是让策略直接持有上下文的引用，这样可以保持策略的独立性和可重用性。
C++策略模式与工厂模式、模板方法模式有何异同？
在设计模式的世界里，很多模式看起来有些相似，但其解决的核心问题和实现机制却大相径庭。策略模式、工厂模式和模板方法模式就是这样一组容易混淆但各有侧重的模式。理解它们的异同，对于选择合适的模式至关重要。
策略模式 (Strategy Pattern)，我们已经详细讨论过，其核心在于运行时行为切换。它通过对象组合（Context has-a Strategy）来实现。上下文对象持有一个策略对象的引用，并委托该策略来执行某个行为。不同的具体策略类封装了不同的算法，客户端可以在运行时动态地更换上下文所使用的策略，从而改变上下文的行为。它关注的是“做什么”和“怎么做”的分离。
工厂模式 (Factory Method Pattern)，则关注的是对象的创建。它的核心思想是定义一个用于创建对象的接口，但让子类决定实例化哪一个类。工厂方法将对象的创建过程封装起来，使得客户端代码不需要知道具体要创建哪个类的实例，从而解耦了客户端与具体产品类之间的依赖。例如，一个日志系统可能需要根据配置创建不同的日志记录器（文件日志、数据库日志、控制台日志），工厂模式就能很好地管理这些日志记录器的创建。它关注的是“如何获取一个对象”。
两者的异同：
相同点： 它们都利用了多态性，并有助于解耦。不同点： 策略模式改变的是对象的行为；工厂模式改变的是对象的创建方式。它们可以结合使用：一个工厂可以用来创建具体的策略对象，然后将这些策略对象注入到上下文中。
模板方法模式 (Template Method Pattern)，与策略模式在表面上看起来都涉及算法的变体，但其实现机制和侧重点完全不同。模板方法模式的核心在于定义一个算法的骨架（在抽象基类中），而将一些具体的步骤延迟到子类中实现。它通过类继承（子类 is-a 父类）来实现。抽象基类定义了一个“模板”方法，其中包含算法的通用结构，以及一些抽象的“基本操作”，这些操作由具体的子类来重写以提供特定的实现。
策略模式与模板方法模式的异同：
相同点： 它们都旨在管理和组织算法的变化。不同点：实现方式： 策略模式使用对象组合，上下文持有策略对象；模板方法模式使用类继承，子类继承并重写父类的部分方法。灵活性： 策略模式允许在运行时动态切换整个算法；模板方法模式在编译时通过子类选择固定的算法变体。一旦子类确定，其算法的骨架就固定了，只能改变其中定义的“钩子”方法。变化粒度： 策略模式通常改变的是整个算法；模板方法模式允许改变算法的特定步骤，而算法的整体流程保持不变。
在我看来，如果你需要的是“这个对象现在做A，过一会儿做B”，那么策略模式是你的选择。如果你需要的是“给我一个X对象，但我不想知道它是怎么造出来的”，那工厂模式更合适。而如果你面对的是“这个流程总共有五个步骤，其中第三步可以有多种实现，但其他步骤都是固定的”，那么模板方法模式可能就是你需要的。理解这些细微的差别，是成为一个优秀C++设计师的关键一步。
以上就是C++策略模式实现运行时算法切换的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474440.html
微信扫一扫 
支付宝扫一扫 
