一.设计背景
现实生活中，我们要做一件事情或者完成某项工作，往往有很多种途径。比如我们出游，可以选择坐汽车，坐火车，土豪点的选择是坐飞机。还有我们现在线下的支付方式也有了很多种选择，以前在外面忘了带钱的话可能一瓶水都难以买到，现在只要我们手机在身上，可以用微信或者支付宝。
在软件设计层面，我们把各种支付方式叫做策略。如果不考虑设计模式的话，我们可能会在一个类中用if..else方式来选择支付方式，即
if(type == 1){ //微信支付 }else if(type == 2){ // 支付宝支付 }else if(type == 3){ //现金支付 }
但如果以后要改变支付方式，比如不能用微信支付了，或者新增了其他支付方式，我们就要改变这个类，这会带来代码维护的麻烦。
二.模式结构和定义
下图为策略模式的结构：
从图中我们看到，客户context拥有成员变量strategy（策略），至于需要用到那种策略，我们可以在构造器中指定。策略模式的定义是：定义算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。这算法体现了几个设计原则，第一、把变化的代码从不变的代码中分离出来；第二、针对接口编程而不是具体类（定义了策略接口）；第三、多用组合，少用继承（客户通过组合方式使用策略）。
三.应用实例
下面以公司职员的工作内容为例介绍策略模式
定义策略接口，就是工作内容
interface DoWorking{
public void comeOn();
}编码类实现策略接口DoWorking
class Coding implements DoWorking{
public void comeOn(){
System.out.println("I'm coding....");
}
}
审计类实现策略接口DoWorking
class auditing implements DoWorking{
public void comeOn(){
System.out.println("我正在审计财务报表....");
}
}
招聘类实现策略接口DoWorking
class recruiting implements DoWorking{
public void comeOn(){
System.out.println("I'm recruting new employees...");
}
}
定义客户端职员类，其中包含成员变量doWorking（策略），以及开展工作的方法startWork()
class Employee{
public DoWorking doWorking;//组合的方式使用策略
public void startWork(){
doWorking.comeOn();
}
}
客户端程序员继承职员类
class Coder extend Employee{
public Coder(){
doWorking = new Coding();//使用编码策略
}
}
测试程序员调用策略
public class StrategyClient {
public static void main(String[] args){
Employee coder = new Coder();
coder.startWork();
}
}
运行结果：
I’m coding….
四.优点和不足
1.优点
（1）.体现了“对修改关闭，对扩展开放”原则，客户端增加行为不用修改原有代码，只要添加一种策略即可。
（2）.避免了使用多重转移语句（if..else if..else）。
（3）.提供了可以替换继承关系的办法： 继承提供了另一种支持多种算法或行为的方法。你可以直接生成一个Context类的子类，从而给它以不同的行为。但这会将行为硬行编制到 Context中，而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。最后你得到一堆相关的类 , 它们之间的唯一差别是它们所使用的算法或行为。 将算法封装在独立的Strategy类中使得你可以独立于其Context改变它，使它易于切换、易于理解、易于扩展。
2.缺点
（1）.每添加一个策略就要增加一个类，当策略过多是会导致类数目庞大。
（2）.客户端需明确知道系统有哪些策略可以使用，当策略过多时客户端的学习成本较高。
五.使用场景
1.如果一个系统里有很多类，他们只是某个行为不同时，使用策略模式可以让一个对象在许多行为中选择一种行为。
2.一个系统需要动态地在几种算法中选择一种。
3.有多重转移条件语句考虑使用策略模式。
