我眼中的设计模式---策略模式

 作为开篇。有必要说明下。写文章不是我的强行，只是作为一个记录而已

     首先 对于策略模式给一个定义吧！策略模式：定义了算法簇，分别对其进行了封装，他们之间可以互换。这样做的话，可以让算法的变化独立于算法的客户端！

    这里先举一个鸭子的实例。对于一个鸭子，他有很多行为，比如叫，飞行，但不同种类的的鸭子，它有不同的行为。所以可能会有下面这种做法

 

package com.ssh.exercise;  
  
public class Duck {  
      
      
     public void swim() {  
        System.out.println("所有鸭子都会游泳！");  
    }  
      
     public void quack(){  
         System.out.println("quack");  
     }  
       
     public void fly(){  
         System.out.println("fly");  
     }  
       
}  

 

具体的实例去实现覆盖对应的方法，如下面的代码所示：
 
package com.ssh.exercise;  
  
public class WoodDuck extends Duck{  
  
    @Override  
    public void quack() {  
        System.out.println("呱呱叫");  
    }  
  
    @Override  
    public void fly() {  
        System.out.println("木头鸭不会叫");  
          
    }  
      
      
  
}

但这样做的结果是：为了复用的目的而使用继承，反而效果不佳，一来并不是所有子类都具备超类的行为，代码在多了子类中重复，也很难知道所有鸭子的全部行为，运行时行为不容易改变，改变一个，会造成其他鸭子不想要的改变！
看到这里，你可能会想到把fly，quack从超类中单独出去，定义flyable，quackable的接口，子类来实现。虽然这样的做法，可以解决一部分的问题，但只是从一个噩梦到另外一个噩梦，想想，java是单继承的，如果，在会飞的鸭子里面，飞行动作又有其他变化呢。会不会造成代码无法复用，如果有很多子类，那么去修改那么多子类的飞行或者叫的行为不觉得很麻烦么？

想想开篇的定义，定义算法族，就是把可变化的东西提取出来，封装！

 

那我们就可以如下做：先定义fly和quack的接口，不同的飞行行为，或者喊叫的行为去实现对应的接口，这样一来对于不同的鸭子，就只要实现行为的实现类就可以了，代码比较简单。我就不贴了。

 

策略模式的设计原则:找出应用中可能需要变化之处，把他们独立起来，不要和那些不需要变化的代码混合在一起。尽量针对接口编程。不要针对实现编程，多用组合，少用继承