一直想把常见的设计模式系统地学习一遍，结果和大多数人一样，过了几天就没能坚持下去了。我发现学习这件事情急不得，往往你越急就越容易半途而废。反而是沉住气，一天学习一点，然后把它放在脑子里面，在碎片时间里“拿”出来捋一捋，像发酵一样，渐渐地吸收消化为自己的东西，然后再开始学习下一个知识点。好了，闲话说了这么多，我们开始吧！
昨天学习了设计模式中的策略模式，这个模式的思想就是：
- 面向接口编程
- 把应用中可能需要变化之处独立出来，不要和那些不需要变化的代码混在一起。
我们再来看看维基百科对于c策略模式的定义:
策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。比如每个人都要“交个人所得税”，但是“在美国交个人所得税”和“在中国交个人所得税”就有不同的算税方法。
策略模式：
定义了一族算法（业务规则）；
封装了每个算法；
这族的算法可互换代替（interchangeable）
看的似懂非懂的，我们通过一个例子来深入的揣摩这个神奇的设计模式。
情景：一个模拟游戏中需要用到很多不同类型的鸭子，请编写代码以生成不同的鸭子对象。
你可能想到编写一个Duck抽象超类然后让具体的鸭子类去继承它，在子类中重写超类中的方法，实现“个性化”，于是你写的代码可能就是下面这个样子的：
public class Duck{
public void quack(){
//鸭子的叫声
}
public void swim(){
//鸭子会游泳
}
public display(){
//鸭子的羽毛的颜色
}
然后再定义一个子类：
public class MallardDuck extends Duck{
public void display(){
System.out.println("我的羽毛是绿色的");
}
}
乍一看好像感觉并没有什么不对啊？确实上面这种写法在项目的初期可能确实能够达到用户突出的需求，但是需求是可能变化的，你应该思考的是：当需求改变的时候你的代码是否能够灵活应对，这在工程上叫做低耦合。
比如，现在需求改变了，我要有一种会飞的鸭子，怎么办？你可能会说这有什么难的，在Duck类里面添加一个fly方法不就可以了吗？但是新的问题又来了：如果你在超类设置了fly方法，就意味着每一个子类都会拥有fly方法，这肯定不能忍啊，你可能又会想到补救措施：在那些不会飞的鸭子子类中重写一遍fly方法。这样可以是可以，如果400种鸭子有200种不会飞的鸭子子类，可能你整天都在那里做重写工作了。
那么用接口呢？让那些会飞的鸭子实现接口中的fly方法？这就是典型的从一个坑跳到了另外一个坑，你现在就要把会飞的那200种鸭子都要实现一遍fly方法。
好了，上面我们把问题都梳理了一遍。我们重新审视一次我们遇到的问题。在例子中，总共有两种飞行行为：会飞的和不会飞的。我们可以不把它写进类里面，因为我们已经看到，不同鸭子的飞行行为是不一样的。这就是我们上面提到的把要变化的部分提取出来。其实这是设计模式中很重要的一个设计原则：多用组合，少用继承。我们设计一个飞行接口，让具体的飞行行为类去实现它，到底怎么飞由类自己实现。而我们的Duck类将飞行接口当成是鸭子的一个成员变量。由于Duck类知道这个飞行行为接口肯定有一个fly方法，所以我可以大胆的在Duck类里面调用这个变量的fly方法（这就是面向接口编程），而具体怎么飞要由具体的飞行行为来决定，这在Java中叫做后期绑定。
原理解释清楚了，上代码：
鸭子类：
public abstract class Duck {
protected FlyBehavior flyBehavior;
protected QuackBehavior quackBehavior;
public abstract void display();
public void performQuack(){
quackBehavior.quack();
}
public void performFly(){
flyBehavior.fly();
}
public void swim(){
System.out.println("所有的鸭子都能漂浮于水面。");
}
public void setFlyBehavior(FlyBehavior flyBehavior){
this.flyBehavior=flyBehavior; //为了代码更加灵活，这里添加设置
飞行行为的方法，下同
}
public void setQuackBehavior(QuackBehavior quackBehavior){
this.quackBehavior=quackBehavior; //修改鸭子的叫声，有的呱呱叫，有的小鸭还不会叫
}
}
飞行行为接口：
public interface FlyBehavior {
void fly();
}
叫声接口：
public interface QuackBehavior {
void quack();
}
具体的飞行行为类one：
public class FlyWithWings implements FlyBehavior {
public void fly(){
System.out.println("我可以飞。");
}
}
具体的飞行行为类two：
public class FlyNoWay implements FlyBehavior {
public void fly(){
System.out.println("我不能飞");
}
}
具体的叫声类one：
public class Quack implements QuackBehavior {
public void quack(){
System.out.println("呱呱叫");
}
}
具体的叫声类two：
public class MuteQuack implements QuackBehavior {
public void quack(){
System.out.println("<我不能叫>");
}
}
好了，部件代码都写好了，我们来讲它组装组装：
野鸭：
public class MallardDuck extends Duck {
public MallardDuck(){
quackBehavior=new Quack();
flyBehavior=new FlyWithWings();
}
public void display(){
System.out.println("我是野鸭");
}
}
模型鸭（假的鸭子）：
public class ModelDuck extends Duck {
public ModelDuck(){
setFlyBehavior(new FlyNoWay());
setQuackBehavior(new MuteQuack());
}
public void display(){
System.out.println("我是模型鸭");
}
}
我们可以感受到，经过改写后的代码灵活多了，这种灵活主要是来源于可以动态的组合鸭子的行为，而非死板的继承方式。
我们再次复习一下策略模式的几个设计原则作为结尾吧：
- 面向接口编程，而非面向实现编程
- 多用组合，少用继承
- 抽离易改变的代码
我是在校学生，目前大三，如有写的不对的地方，欢迎指正，谢谢！另外,设计模式文章准备写成一个系列，欢迎follow( _ )
