设计模式之策略模式

2016-04-25 本文已影响141人 Neulana

一直想把常见的设计模式系统地学习一遍，结果和大多数人一样，过了几天就没能坚持下去了。我发现学习这件事情急不得，往往你越急就越容易半途而废。反而是沉住气，一天学习一点，然后把它放在脑子里面，在碎片时间里“拿”出来捋一捋，像发酵一样，渐渐地吸收消化为自己的东西，然后再开始学习下一个知识点。好了，闲话说了这么多，我们开始吧！

昨天学习了设计模式中的策略模式，这个模式的思想就是：

面向接口编程
把应用中可能需要变化之处独立出来，不要和那些不需要变化的代码混在一起。

我们再来看看维基百科对于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( ^_ )

设计模式之策略模式

猜你喜欢

热点阅读