各行各业都有术语，如 天王盖地虎，宝塔镇河妖，懂行的人，才能理解其中意义。
设计模式 可谓是我们程序员的术语了，当别人问你程序怎么写的时候，这个时候，你对他说出一大串“术语”（策略模式、代理模式、工厂模式...），不懂设计模式的人听得云里雾里，心想此人在装逼；而懂设计模式的人，心里就会想此人逼格好高...
设计模式带给我们的好处：
1.更容易看懂开源库的代码，开源库中代码会大量的使用设计模式，如果我们懂设计模式，我们就会抓住重点，跳过模版的代码，关注核心代码
2.减少沟通成本 前提是双方都有准确的设计模式的理解
3.软件程序更加灵活可变
4.升职加薪，迎娶白富美，走向人生巅峰...
设计模式本来就是解决实际问题，是经过时间推敲，经过前人的打磨而产出的设计模版，所以我们要学习这种术语，就要先知道每一种设计模式到底是解决什么问题的。
我们来看一下 策略模式 可以解决什么问题
先来了解这样一个场景：
我们做了一个游戏，准备上线，内包含了支付功能，1.0版本只支持微信支付。我们定义一个Player接口，有这个购买的动作。
public interface Player {
void buy(String product);
void play();
}
public class WeiXinPlayer implements Player {
private static final String TAG = "WeiXinPlayer";
@Override
public void buy(String product) {
Log.d(TAG, "WeiXin pay:"+product);
}
@Override
public void play() {
}
}
这个时候，产品说只有一种支付方式太单一了，支付宝支付也要支持。那就再实现一个AliPlayer
public class AliPlayer implements Player {
private static final String TAG = "AliPlayer";
@Override
public void buy(String product) {
Log.d(TAG, "AliPay:"+product);
}
@Override
public void play() {
}
}
我们将1.1版本发布后，产品又提需求了，我们要支持银联支付、话费支付等支付方式。
没关系！同样实现Player接口，再多写BankPlayer 和 SmsPlayer就好啦！
如上类图，产我们生了4个实体类关联了父类Player，也就是说如果play方法要改动的话，比如玩家从使用拳头打怪变为使用木棍打怪，那么所有的实现这个Player接口的类都要改动，而我们当初仅仅是为了增加支付的方式（实现buy的方法）！
软件的开发过程中，一定会有很多的需求和变化，让我们的程序经受或大或小的改变，如何让我们的程序在变化中，快速的开发并且保持稳定？这个就是设计模式大展身手的地方啦，所以说学习设计模式非常重要！
重新审视一下我们的设计，我们变化的是buy方法，但是由于支付方式的改变，我们不得不实现play方法，我们违反了设计原则之一：开闭原则
开闭原则：对扩展开放，对修改关闭
我们应该对支付方式的增加扩展，而对其他的修改关闭，这样才能减少测试，增加我们的程序的稳定。找出变化的地方 封装变化！
变化的地方就是我们的支付方式的改变，也就是我们Player中的buy方法，我们将其提取封装。定义一个Pay的接口
public interface Pay {
void pay(String product);
}
让我们的支付的都实现这个接口，如WeiXinPay
public class WeiXinPay implements Pay{
private static final String TAG = "WeiXinPay";
@Override
public void pay(String product){
Log.d(TAG, "WeiXin pay:"+ product);
}
}
这样，我们所有支付类型都实现了Pay接口，接下里看下我们对Player接口实现的修改，我们用一个CommonPlayer来作为Player的接口实现，用Pay类型参数接收一个支付实现类，然后在buy方法中，使用的是我们支付具体的实现类的pay方法。
public class CommonPlayer implements Player {
Pay mPay;
public CommonPlayer(Pay pay){
this.mPay = pay
}
@Override
public void buy(String product) {
mPay.pay(product);
}
@Override
public void play() {
}
}
我们使用的时候，将对应的支付方式，传递给CommonPlayer
WeiXinPay weixinPay = new WeiXinPay();
// AliPay aliPay = new AliPay();
CommonPlayer player = new CommonPlayer(weixinPay);
注意：我们是使用组合的方式而非继承的方式，思考一下这样做有什么好处？
如果我们使用继承（实现），由之前的例子可以看到，我们要生成很多的Player实现类，每一个类都有自己的buy方法，并且这个方法是不会变化的，在需求变化到此类的其他接口方法时，我们就需要修改所有实现类，很容易就出现了牵一发而动全身的情况，就会让我们的软件开发举步维艰。我们使用组合的方式就可以避免这样的窘境，组合的好处是，我们可以封装变化，在此例子中我们可以封装支付方式，只需要重新生成实现Pay接口，而不是生成Player实现类，在使用的过程中，并且可以动态的使用支付方式，并且能保证其他代码的稳定。这也是遵循了另一个 设计原则：多用组合，少用继承
我们来看一下我们的类图：
不用怀疑，上面就是我们使用 策略模式 来改善我们的代码，来看一下策略模式的定义：
策略模式：定义算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户
Pay接口以及实现的WeiXinPay、AliPay、BankPay、SmsPay，这些就是我们所定义的算法族，我们一一封装起来，独立于使用它们的客户（即CommonPlayer）
我们再来加深一下印象。我们产品又双叒叕提需求了，因为用户购买了我们道具装备，普通用户只能用拳头打怪，而充值用户就厉害了，98K，M16，AK啥的装备只要你有钱都可以买，那么在play方法中，不一样的装备是不同的。看到这个需求，根据我们学习的策略模式，现在的你是不是胸有成竹了？
最后总结一下我们学习策略模式学习到的东西
设计原则：
1.针对接口编程
2.开闭原则
3.封装变化
4.多用组合，少用继承
策略模式：定义算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户
