设计模式——策略模式

StrategyPattern

策略模式(StrategyPattern)的定义：

定义算法族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户.这里的算法族是指特定的行为的类,通俗的说就是把该特定行为抽取出来封装成一个类.

举个例子：

在我们的鸟类中有形形色色不同种类的鸟,但是这些鸟中有的会飞,有的会叫.还有的不会飞也不会叫(你不能忽视玩具中也有不同的鸟类).当你去设计一个鸟的类的时候,你可能最先想到的是,既然把会飞会叫不会飞不会叫的功能全部写在一个鸟的类里面(这个类我们称它为超类,即父类.),然后写一个子类去继承它,那么子类就有了父类的功能,那有人就有疑问了：如果我的子类是一个鸟类的玩具呢,它不会飞也不会叫,但是继承了父类,也有了该方法啊?这怎么办?这样的设计并不可行.毕竟玩具鸟不会飞也不会叫,但却有飞和叫的功能,这就已经颠覆生物范畴了.于是就有人提出另外一种方法了,那就是单独把会飞会叫的方法分别抽取出来,把他们当作是一个接口,以后只要鸟类会飞的就实现会飞的接口,会叫的就实现会叫的接口.这样不就解决问题了嘛,这时又有人提出疑问了：这样确实是解决了一部分的问题,至少把会叫的跟不会叫的鸟类区分开了.但是重复的代码变多了啊,项目中很n多个子类那么,然后有许多子类需要实现会飞的接口,这工程量多大啊.而且还有很多鸟类的飞行方式是一样的呢,这就意味着代码的冗余性增大了.而且有些代码可能也就差一个参数而已.这…..
我们在这场景中得出以下点出来:

1. 方法实现不能都写在一个父类里(这里是针对以上情景,如果你能确保每个子类都执行相同的方法那么这条可以忽略)
2. 使用接口可以解决一部分问题,但并不是全部,还需做其他组合.下面会介绍.
3. 写重复的代码不单会消耗大量时间,还会被人鄙视.应当把这部分时间花在更多其他的事情上(目前正在努力摆脱这一条)
4. 如果有新的行为引入,修改这个项目对你来说将是个噩梦.因为牵一发而动全身.

策略模式的使用：

1. 把相同的代码尽可能抽取出来.
2. 定义一组特定的行为接口
3. 在父类中把其中一个或一组行为接口作为变量.如果子类需要重写父类的 某个方法,那么最好把父类中该方法作为抽象方法,子类在继承父类时实现该方法即可.同时定义一个或一组方法来代替子类中的行为方法,在方法里调用行为接口中特定行为.(如果想动态设置该行为,那么需要在父类中给出设置设置行为的方法,把行为接口作为参数)
4. 定义一组行为接口的具体实现类,实现特定行为的方法.
5. 子类继承父类,并且在构造函数中初始化行为接口的具体实现类(这里用到了多态)
6. 在子类中调用父类中代替子类行为的方法.
7. 看不明白以上的不要紧,看下面这张图

还看不懂?看一下代码(如果看不懂Java,那我只能帮你到这里了)
####第一步：

public abstract class Duck {    public FlyBehavior flyBehavior;//特定行为接口    public QuackBehavior quackBehavior;//特定行为接口    /**     * 给予动态设置特定行为的接口     * @param fb     */    public void setFlyBehavior (FlyBehavior fb) {        flyBehavior = fb;    }    /**     * 给予动态设置特定行为的接口     * @param qb     */    public void setQuackBehavior(QuackBehavior qb) {        quackBehavior = qb;    }    //替代父类中的行为(原来实现代码是写在父类中的,因为方法不变,内容变,所以把方法抽取出来,让特定行为接口的某个方法来实现方法内容)    public void performFly(){        flyBehavior.fly();    }    //替代父类中的行为(原来实现代码是写在父类中的,因为方法不变,内容变,所以把方法抽取出来,让特定行为接口的某个方法来实现方法内容)    public void performQuack(){        quackBehavior.quack();    }    /**     * 抽象方法(看到这里你可以会想,为什么实现方法不能都是抽象方法就像这个一样?     * 原因很简单,并不是所以的鸭子都会飞会叫,都用抽象,会造成子类中相同代码的数量增多,还不明白就只能帮你到这里了)     */    public abstract void disPlay();}

第二步:

//特定行为接口public interface FlyBehavior {    //每个需要该行为的都要实现以下方法    public void fly();}

第三步:

//具体实现类实现特定行为接口public class FlyWithWings implements FlyBehavior{    public void fly() {        System.out.println("i am flying");    }}

第四步:

//子类继承父类public class ModelDuck extends Duck{    //构造函数中初始化行为具体实现类    public ModelDuck(){        flyBehavior=new FlyNoWay();        quackBehavior=new Quack();    }    @Override    public void disPlay() {        // TODO Auto-generated method stub    }}

第五步：

public class StrategyPatternTest {    /**     * @param args     */    public static void main(String[] args) {        //创建子类并调用父类中某个方法        ModelDuck modelDuck=new ModelDuck();        //这里是调用构造函数中的具体实现类的fly()方法        modelDuck.performFly();//这里输出的是"i am fly"        //动态设置特定行为接口        modelDuck.setFlyBehavior(new FlyRocketPowerd());        //动态设置特定接口后调用的是FlyRocketPowerd接口中的fly()方法        modelDuck.performFly();    }}

总结：

策略模式的优点就在于,它把功能从代码中分离出来的.这就意味着代码的复用性高了,因为这些行为已经和鸭子类的行为无关了,当需要增加新的行为(增加一个特定行为接口),不会影响到既有的行为类,不会影响使用到飞行行为的子类.

如果你还不明白我在说什么…..你就移步去看我的代码吧.(毕竟我也是边学习边总结)

代码地址：策略模式