设计模式之策略模式

设计模式之策略模式

     定义：定义了算法族，分别封装起来，让它们之间能够相互替换，此模式让算法的变法独立于使用算法的客户。

     关于模式的学习原本就是比较头痛的事情，若是但看看理论。就算你知道了它应用的场景。在实际的应用中，你也很难的应用到你的项目中。理解容易，实际的应用更难。

      接下来我要经过一个实例来说解这个设计模式。经过不断的需求变化，来真正的体现设计模式带来的好处，咱们使用一些设计模式，就是让你的程序能够应付客户的不断的需求变化。咱们知道，在咱们实际的开发中，难的不是技术上的问题，而是客户随着开发的进行，他们的需求的不断的变化，这是最头痛的，若是你的程序不能对付客户的变化的话，你就会付出更多的代价。为了让咱们的程序能够健壮，重用，可扩展。利用设计模式的思想去开发编程，能够解决上面的几个问题。这并非惟一的办法，可是比较好的办法。

      咱们的要求是设计一个模拟鸭子游戏的应用程序。（注：这个应用是在Head First 设计模式 一书中的例子）。游戏中会出现各类鸭子，一边游泳戏水，一边呱呱叫。对于这样的要求，咱们首先会运用OO技术，并利用继承的思想，设计一个鸭子的超类（Superclass）,并让各类鸭子继承这个超类。

public class Duck{

    public void quack(){  //呱呱叫

       System.out.println("呱呱叫");

     }

    public void swim(){   //游泳

           System.out.println(" 游泳");

   }

   public  abstract void display(); /*由于外观不同，让子类本身去决定了。*/

}

 对于它的子类只需简单的继承就能够了，并实现本身的display()方法。

//野鸭

public class MallardDuck extends Duck{

    public void display(){

         System.out.println("野鸭的颜色...");

  }

}

//红头鸭

public class RedheadDuck extends Duck{

    public void display(){

         System.out.println("红头鸭的颜色...");

  }

}

这里可能还会有其余颜色的鸭子。经过这个简单的继承咱们知足了客户的要求。

  不幸的是，如今客户又提出了新的需求，想让鸭子飞起来。这个对于咱们OO程序员，在简单不过了，在超类中在加一个方法就能够了。

public class Duck{

    public void quack(){  //呱呱叫

       System.out.println("呱呱叫");

     }

    public void swim(){   //游泳

           System.out.println(" 游泳");

   }

   public  abstract void display(); /*由于外观不同，让子类本身去决定了。*/

  public void fly(){

       System.out.println("飞吧！鸭子");

 }

}

在子类中只需简单的覆盖。

//残废鸭

public class DisabledDuck extends Duck{

    public void display(){

         System.out.println("残废鸭的颜色...");

  }

  public void fly(){

   //覆盖，变成什么事都不作。

 }

}

其它会飞的鸭子不用覆盖。

这样全部的继承这个超类的鸭子都会fly了。可是问题又出来了，客户又提出有的鸭子会飞，有的不能飞。客户就是那样的让咱们头痛啊，他们的需求会随着咱们的开发而改变的。

这时咱们须要作的是对会飞的鸭子重写fly方法，对于不能飞的也重写，但在方法里什么也不写，只是一个空方法，没有任何实现。只是简单覆盖超类中的fly方法。这样能够知足暂时的需求了，但对咱们的维护带来了麻烦。对于一些不会叫的，也不会飞的鸭子的子类中，夹杂了一些没有意义的代码，就是对一些超类方法的覆盖。  

     对于上面的设计，你可能发现一些弊端，若是超类有新的特性，子类都必须变更，这是咱们开发最不喜欢看到的，一个类变让另外一个类也跟着变，这有点不符合OO设计了。这样很显然的耦合了一块儿。

      这时，咱们会立刻想到运用接口来消除这种弊端。咱们把容易引发变法的部分提取出来并封装之，来应付之后的变法。虽然代码量加大了，但可用性提升了，耦合度也下降了。同时也具备很强的扩展性，也真正的利用了OO设计思想。

   咱们把Duck中的fly方法和quack提取出来。

   public interface Flyable{

     public void fly();

 }

  public interface Quackable{

    public void quack();

 }

 最后Duck的设计成为：

public class Duck{

    public void swim(){   //游泳

           System.out.println(" 游泳");

   }

   public  abstract void display(); /*由于外观不同，让子类自 己去决定了。*/

}

 而MallardDuck,RedheadDuck,DisabledDuck 就能够写成为：

//野鸭

public class MallardDuck extends Duck  implements Flyable,Quackable{

    public void display(){

         System.out.println("野鸭的颜色...");

  }

  public void fly(){

   //实现该方法

 }

  public void quack(){

   //实现该方法

 }

}

//红头鸭

public class RedheadDuck extends Duck implements Flyable,Quackable{

    public void display(){

         System.out.println("红头鸭的颜色...");

  }

  public void fly(){

   //实现该方法

 }

  public void quack(){

   //实现该方法

 }

}

//残废鸭 只实现Quackable（能叫不能飞）

public class DisabledDuck extends Duck implements Quackable{

    public void display(){

         System.out.println("残废鸭的颜色...");

  }

  public void quack(){

   //实现该方法

 }

}

   这样已设计，咱们的程序就下降了它们之间的耦合。

   如今咱们知道使用继承并不能很好的解决问题，由于鸭子的行为在子类中不断的变化，而且让所用的子类都有这些行为是不恰当的。Flyable和Quackable接口一开始彷佛还挺不错的，解决了问题（只有会飞到鸭子才实现 Flyable），可是Java接口不具备实现代码，因此实现接口没法达到代码的复用。这时咱们有一个设计原则：找出应用中可能须要变化之处，把它们独立出来，不要和那些不须要变化的代码混在一块儿。

    如今咱们根据这个设计原则，咱们上面的设计还存在问题。咱们因该如何解决呢？

    如今，为了要分开“变化和不变化的部分”，咱们准备创建两组类（彻底远离Duck类），一个是"fly"相关的，另外一个是“quack”相关的，每一组类将实现各自的动做。比方说，咱们可能有一个类实现“呱呱叫”，另外一个类实现“吱吱叫”，还有一个类实现“安静”。

   咱们如何设计实现飞行和呱呱叫的行为的类呢？咱们为了让咱们的程序有弹性，减少耦合。咱们又必须遵循第二个设计原则：针对接口编程，而不是针对实现编程。

  看看咱们具体的实现吧，实现胜于理论。

  首先写两个接口。FlyBehavior(飞行行为)和QuackBehavior（叫的行为）.

 public interface FlyBehavior{

    public void fly();    

}

public interface QuackBehavior{

    public void quack();

}

咱们在定义一些针对FlyBehavior的具体实现。

public class FlyWithWings implements FlyBehavior{

   public void  fly(){

    //实现了全部有翅膀的鸭子飞行行为。

  }

}

public class FlyNoWay implements FlyBehavior{

   public void  fly(){

     //什么都不作，不会飞

  }

}

针对QuackBehavior的几种具体实现。

public class Quack implements QuackBehavior{

   public void quack(){

     //实现呱呱叫的鸭子

 }

}

public class Squeak implements QuackBehavior{

   public void quack(){

     //实现吱吱叫的鸭子

 }

}

public class MuteQuack implements QuackBehavior{

   public void quack(){

     //什么都不作，不会叫

 }

}

  这样的设计，可让飞行和呱呱叫的动做被其余的对象复用，由于这些行为已经与鸭子类无关了。而咱们增长一些新的行为，不会影响到既有的行为类，也不会影响“使用”到飞行行为的鸭子类。

    最后咱们看看Duck 如何设计。

    public class Duck{

     FlyBehavior flyBehavior;//接口

     QuackBehavior quackBehavior;//接口

      public Duck(){}

      public abstract void display();

      public void swim(){

       //实现游泳的行为

       }

      public void performFly(){

           flyBehavior.fly();//这时鸭子对象不亲自处理飞行行为，而是委托给flyBehavior引用的对象。

    }

    public void performQuack(){

         quackBehavior.quack();();//这时鸭子对象不亲自处理叫的行为，而是委托给quackBehavior引用的对象。

   }

}

 看看MallardDuck如何实现。

public class MallardDuck extends Duck{

      public MallardDuck（） {

       flyBehavior = new FlyWithWings ();

       quackBehavior = new Quack();

     //由于MallardDuck 继承了Duck，全部具备flyBehavior 与quackBehavior 实例变量 }

   public void display(){

    //实现

  }

}

这样就知足了便可以飞，又能够叫，同时展示本身的颜色了。

  这样的设计咱们能够看到是把flyBehavior ，quackBehavior 的实例化写在子类了。咱们还能够动态的来决定。

 咱们只需在Duck中加上两个方法。

 public class Duck{

     FlyBehavior flyBehavior;//接口

     QuackBehavior quackBehavior;//接口

     public void setFlyBehavior(FlyBehavior flyBehavior){

           this.flyBehavior = flyBehavior;

    }

   public void setQuackBehavior(QuackBehavior quackBehavior  {

           this.quackBehavior= quackBehavior;

    }

}

   你们看到这样的方法应该知道它是利用依赖注入的思想，动态的来改变鸭子的行为。

 在测试的类中，咱们能够这样写。

 public class Test{

     public static void main(String[] args){

        //通常的用法：

         Duck mallard = new MallardDuck();

         mallard.performFly();

         mallard .perforeQuack();

       //动态的改变

       mallard.setFlyBehavior(new FlyRocketPowered);//具备火箭动力的飞行能力

     mallard.performFly();

     }

 }

     这样的用法其实就是Spring 中的一个核心机制，Ioc依赖注入思想。

      咱们讲了这么些，其实就是策略模式的应用。咱们写了这么多，就是为了让你更加明白这个设计模式的应用场景。

      策略模式：定义了算法族（飞行行为中的各类实现<当作一族算法>和呱呱叫行为中的各类实现<当作一族算法>），分别分装起来，让它们之间能够相互调用，此模式让算法的变法（就是飞行行为和呱呱叫的行为）独立于使用算法的客户。