策略模式(StrategyPattern)的定义：
定义算法族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户.这里的算法族是指特定的行为的类,通俗的说就是把该特定行为抽取出来封装成一个类.
举个例子：
在我们的鸟类中有形形色色不同种类的鸟,但是这些鸟中有的会飞,有的会叫.还有的不会飞也不会叫(你不能忽视玩具中也有不同的鸟类).当你去设计一个鸟的类的时候,你可能最先想到的是,既然把会飞会叫不会飞不会叫的功能全部写在一个鸟的类里面(这个类我们称它为超类,即父类.),然后写一个子类去继承它,那么子类就有了父类的功能,那有人就有疑问了：如果我的子类是一个鸟类的玩具呢,它不会飞也不会叫,但是继承了父类,也有了该方法啊?这怎么办?这样的设计并不可行.毕竟玩具鸟不会飞也不会叫,但却有飞和叫的功能,这就已经颠覆生物范畴了.于是就有人提出另外一种方法了,那就是单独把会飞会叫的方法分别抽取出来,把他们当作是一个接口,以后只要鸟类会飞的就实现会飞的接口,会叫的就实现会叫的接口.这样不就解决问题了嘛,这时又有人提出疑问了：这样确实是解决了一部分的问题,至少把会叫的跟不会叫的鸟类区分开了.但是重复的代码变多了啊,项目中很n多个子类那么,然后有许多子类需要实现会飞的接口,这工程量多大啊.而且还有很多鸟类的飞行方式是一样的呢,这就意味着代码的冗余性增大了.而且有些代码可能也就差一个参数而已.这.....
我们在这场景中得出三点出来:
1.方法不能都写在一个父类里(这里是针对以上情景,如果你能确保每个子类都执行相同的方法 那么这条可以忽略)
2.使用接口可以解决一部分问题,但并不是全部,还需做其他组合.下面会介绍.
3.写重复的代码不单会消耗大量时间,还会被人鄙视.应当把这部分时间花在更多其他的事情上(目前正在努力摆脱这一条)
策略模式的使用：
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();
}
}
总结：
策略模式的优点就在于,它把功能从代码中分离出来的.这就意味着代码的复用性高了,因为这些行为已经和鸭子类的行为无关了,当需要增加新的行为(增加一个特定行为接口),不会影响到既有的行为类,不会影响使用到飞行行为的子类.
如果你还不明白我在说什么.....你就移步去看我的代码吧.(毕竟我也是边学习边总结)
代码地址：策略模式
