策略模式本质
分离算法，选择实现
对设计原理的实现
从设计原则上来看，策略模式很好地体现了开-闭原则。通过把一系列可变的算法进行封装，并定义出合理的使用结构，使得在系统出现新算法时，额能很容易的把算法加入到已有的系统中，而已有的实现不需要做任何更改。
何时选择策略模式
- 出现许多相关的类，仅仅是行为有差别的情况下，可以使用策略模式来使用多个行为中的一个配置一个类的方法，实现算法动态切换。
- 出现同一个算法，有很多不同实现的情况下，可以使用策略模式来把这些“不同的实现”实现成为一个算法的类层次。
- 需要封装算法中，有与算法相关数据的情况下，可以使用策略模式避免暴露这些跟算法相关的数据结构。
- 出现抽象一个定义了很多行为的类，并且是通过多个if-else语句来选择这些行为的情况下，可以使用策略模式来代替这些条件语句。
优缺点
优点：
- 定义一系列算法
- 避免多重条件语句
- 更好的扩展性
缺点
- 客户必须了解每种策略的不同
- 怎讲对象数目
- 只适合扁平的算法结构（一系列算法的地位是平等的，是可以相互替换的，在运行时刻只有一个算法被使用，限制了算法的使用层级，使用的时候不能嵌套使用）
示例：工资支付的实现思路
功能：工资支付方式的问题。很多企业的工资支付方式是很灵活的，可支付的方式是很多的，比如：人民币现金支付、美元现金支付、银行转账到工资账号、银行转账到工资卡，甚至可能工资转股权等方式。
要实现这样的功能，策略模式是一个很好的选择，在实现这个功能时，不同的策略算法需要的数据是不一样的，如：现金支付就不需要银行账号，而银行转账就需要账号。这就导致在设计策略接口中的方法时，不太好确定参数的个数，而且，就算现在吧所有参数都列上了，今后扩展呢？难道再来修改策略接口吗？那到底如何实现才能扩展时最方便呢？
解决方案一：就是把上下文（context）当作参数传递给策略对象。这样，如果要扩展新的策略实现，只需要扩展上下文就可以了，已有的实现不需要做任何更改。
实现代码：
/**
* 支付工资的策略接口，公司有多种支付工资的算法
* 比如：现金，银行卡，美元支付等
**/
public interface PaymentStrategy{
//公司给某人真正支付工资
//@param ctx 支付工资的上下文，里面包含算法需要的数据
public void pay(PaymentContext ctx);
}
//人民币现金支付
public class RMBCash implements PaymentStrategy{
public void pay(PaymentContext ctx){
System.out.println("现金给"+ctx.getUserName()+"人民币现金支付"+ctx.getMoney()+"元");
}
}
//美元现金支付
public class DollarCash implements PaymentStrategy{
public void pay(PaymentContext ctx){
System.out.println("现金给"+ctx.getUserName()+"美元现金支付"+ctx.getMoney()+"元");
}
}
//支付工资的上下文，每个人的工资不同，支付方式也不同
public class PaymentContext{
private String userName = null;
private double money = 0.0;
//支付工资的方式的策略接口
private PaymentStrategy strategy = null;
//构造函数，传入被支付工资的人员，应支付的金额和具体的支付策略
//userName 被支付工资的人员 money 应支付的金额 strategy 具体的支付策略
public PaymentContext (String userName, double money, PaymentStrategy strategy){
this.userName = userName;
this.money = money;
this.strategy = strategy;
}
//省略get方法，只有get方法，让策略算法在实现的时候，根据需要来获取上下文的数据
//立即支付工资
public void payNow(){
//使用客户希望的支付策略来支付工资
this.strategy.pay(this);
}
}
//客户端
public class Client{
public static void main(String[] agrs){
//创建相应的支付策略
PaymentStrategy strategyRMB = new RMBCash();
PaymentStrategy strategyDollar = new DollarCash();
//准备小李的支付工资上下文
PaymentContext ctx1 = new PaymentContext ("小李",5000,strategyRMB);
//向小李支付工资
ctx1.payNow();
//切换一个人，给petter支付工资
PaymentContext ctx2 = new PaymentContext ("petter",8000,strategyDollar);
ctx2.payNow();
}
}
扩展示例
现在我们要加一种支付方式，要求能支付到银行卡
代码示例：
//扩展的支付上下文对象
public class PaymentContext2 extends PaymentContext{
//银行账号
private String account = null;
//构造函数
public PaymentContext2 (String userName, double money, String account, PaymentStrategy strategy){
super(userName,money, strategy);
this.account = account;
}
public String getAccount(){return account;}
}
public class Card implements PaymentStrategy{
public void pay(PaymentContext ctx){
PaymentContext2 ctx2 = (PaymentContext2)ctx;
System.out.println("现在给"+ctx2.getUserName()+"的"+ctx2.getAccount()+"账号支付了"+ctx.getMoney()+"元");
}
}
public class Client {
public static void main(String[] agrs){
PaymentStrategy strategyCard = new Card();
PaymenttContext ctx= new PaymentContext2("小王",9000,"00121113",strategyCard);
ctx.payNow();
}
}
另一种扩展方式：
上面那种方式是通过上下文对象来准备新的算法需要的数据，还有一种就是通过策略的构造函数来传入新算法需要的数据，这样实现就不需要扩展上下文了，直接添加一个新的算法实现就可以了。
代码示例：
public class Card2 impements PaymentStrategy{
//账号信息
private String account = "";
//构造函数
public Card2(String account){
this.account = account;
}
public void pay(PaymentContex ctx){
System.out.println("现在给"+ctx2.getUserName()+"的"+ctx2.getAccount()+"账号支付了"+ctx.getMoney()+"元");
}
}
两种实现扩展方式的比较：
对与扩展上下文的方式
优点：
- 这样实现，使所有策略的风格更统一；
- 在上下文添加的数据可以视为公共数据，别的相应算法也能用上；
缺点：
1. 如果这些数据只是用于特定的算法，这样数据就有点浪费；
2. 每次添加新的算法都去扩展上下文，容易造成复杂的上下文对象层次；
对与在策略算法的实现上添加自己需要的数据方式
优点：
1. 实现简单
缺点：
1. 和其他策略算法的实现方式不一样
2. 外部使用这个策略算法的时候也不一样，难以以一个统一的方式来动态切换策略算法。