C++设计模式（5）：策略模式

一、背景

在软件开发过程中，我们经常遇到实现一个功能可能需要多种不同的算法或者策略的情形，我们会根据上下文决定使用哪一种算法或者策略完成该功能。一般的做法是实现一个功能函数，通过入参结合if - else if - else来判断使用哪一种算法来完成该功能。试想，如果我们现在增加了一种实现该功能的算法，那么我们必须修改这个功能函数，为它加上对应的else if处理分支。这种做法违反了类设计原则之一的“开闭原则”，灵活性和扩展性差。

二、策略模式定义

策略模式：定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化，策略模式是一种对象行为型模式。

模式分析
（1）策略模式是一个比较容易理解和使用的设计模式，策略模式是对算法的封装，它把算法的责任和算法本身分割开，委派给不同的对象管理。策略模式通常把一个系列的算法封装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。

（2）在策略模式中，应当由客户端自己决定在什么情况下使用什么具体策略角色。

（3）策略模式仅仅封装算法，提供新算法插入到已有系统中，以及老算法从系统中“退休”的方便，策略模式并不决定在何时使用何种算法，算法的选择由客户端来决定。这在一定程度上提高了系统的灵活性，但是客户端需要理解所有具体策略类之间的区别，以便选择合适的算法，这也是策略模式的缺点之一，在一定程度上增加了客户端的使用难度。

三、模式角色和模式类图

Context（环境类）
环境类是使用算法的角色，它在解决某个问题时可以采用多种策略。在环境类中维持一个对抽象策略类的引用实例，用于定义所采用的策略。

Strategy（抽象策略类）
它为所支持的算法声明了抽象方法，是所有策略类的父类，它可以是抽象类或具体类，也可以是接口。环境类通过抽象策略类中声明的方法在运行时调用具体策略类中实现的算法。

ConcreteStrategy（具体策略类）
它实现了在抽象策略类中声明的算法，在运行时，具体策略类将覆盖在环境类中定义的抽象策略类对象，使用一种具体的算法实现某个业务处理。

代码示例：

#include<iostream>
using namespace std;

/*抽象策略类（可为抽象类、接口）*/
class Strategy {
public:
	/* 变化的策略 */
	virtual void algorithm() = 0;
};
/* 具体的策略A类 */
class ConcreteStrategyA:public Strategy {
public:
	void algorithm() {
		cout<<"ConcreteStrategyA: algorithm excute."<<endl;
	}
};
/* 具体的策略B类 */
class ConcreteStrategyB:public Strategy {
public:
	void algorithm() {
		cout<<"ConcreteStrategyB: algorithm excute"<<endl;
	}
};
/* 具体的策略C类 */
class ConcreteStrategyC:public Strategy {
public:
	void algorithm() {
		cout<<"ConcreteStrategyC: algorithm excute"<<endl;
	}
};
/* Context环境类*/
class Context{
private:
	Strategy *strategy = NULL;
public:
	/* 构造函数 */
	Context(Strategy *s):strategy(s){}
	
	/* 动态设置策略接口*/
	void setStrategy(Strategy *s) {
		this->strategy = s;
	} 
	void algorithm(){
		strategy ->algorithm();
	}
};
int main() {
	Context *context = new Context(new ConcreteStrategyA());
	context->algorithm();

	context->setStrategy(new ConcreteStrategyB());
	context->algorithm();

	context->setStrategy(new ConcreteStrategyC());
	context->algorithm();
	return 0;
}

四、策略模式总结

1. 优点

（1）策略模式提供了对 “开闭原则” 的完美支持，用户可以在不修改原有系统的基础上选择算法或行为，也可以灵活地增加新的算法或行为。

（2）策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族，恰当使用继承可以把公共的代码移到抽象策略类中，从而避免重复的代码。

（3）策略模式提供了一种可以替换继承关系的办法。如果不使用策略模式而是通过继承，这样算法的使用就和算法本身混在一起，不符合 “单一职责原则”，而且使用继承无法实现算法或行为在程序运行时的动态切换。

（4）使用策略模式可以避免多重条件选择语句。多重条件选择语句是硬编码，不易维护。

（5）策略模式提供了一种算法的复用机制，由于将算法单独提取出来封装在策略类中，因此不同的环境类可以方便地复用这些策略类。

2. 缺点
（1）客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。
（2）策略模式将造成系统产生很多具体策略类，任何细小的变化都将导致系统要增加一个新的具体策略类。
（3）无法同时在客户端使用多个策略类，也就是说，在使用策略模式时，客户端每次只能使用一个策略类，不支持使用一个策略类完成部分功能后再使用另一个策略类来完成剩余功能的情况。

3. 适用场景
（1）一个系统需要动态地在几种算法中选择一种，那么可以将这些算法封装到一个个的具体算法类中，而这些具体算法类都是一个抽象算法类的子类。换言之，这些具体算法类均有统一的接口，根据 “里氏代换原则” 和面向对象的多态性，客户端可以选择使用任何一个具体算法类，并只需要维持一个数据类型是抽象算法类的对象。

（2）一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重条件选择语句来实现。此时，使用策略模式，把这些行为转移到相应的具体策略类里面，就可以避免使用难以维护的多重条件选择语句。

（3）不希望客户端知道复杂的、与算法相关的数据结构，在具体策略类中封装算法与相关的数据结构，可以提高算法的保密性与安全性。

4. 模式对比

状态模式的类图和策略模式类似，并且都是能够动态改变对象的行为。但是状态模式是通过状态转移来改变 Context 所组合的 State 对象，而策略模式是通过 Context 本身的决策来改变组合的 Strategy 对象。所谓的状态转移，是指 Context 在运行过程中由于一些条件发生改变而使得 State 对象发生改变，注意必须要是在运行过程中。

状态模式主要是用来解决状态转移的问题，当状态发生转移了，那么 Context 对象就会改变它的行为；而策略模式主要是用来封装一组可以互相替代的算法族，并且可以根据需要动态地去替换 Context 使用的算法。