设计模式的引入--策略模式

以一个有关鸭子的电子游戏“SimUDuck”开始，初始设计为

这时，有了一个新的需求，需要让鸭子可以飞

　　第一次设计：（在父类Duck上加一个fly方法，此时所有子类都继承该方法）

然而，经理在演示该项目时，用的是橡胶鸭子，并表示橡胶鸭子不应该会飞(忧伤的程序员。)

该怎么解决这个问题呢?(给一个父类增加了方法，可是部分子类不需要该方法，甚至是不能有该方法)

　　第二次设计：（增加Flyable接口和Quackable接口，让有需要的鸭实现该接口）

的确这样设计解决我们之前的问题，每个鸭子都有自己所需要的方法，可同时该方法造成了代码冗余，违背了DRY原则

该怎么解决这个问题呢？（每个子类都需要实现接口，导致各子类间代码重复冗余）

　　第三次设计：（对接口进行不同的实现，此时Duck类不在继承或者实现接口，而是在类中实例化一个对象，此时，Duck类与Fly和Quack之间将不存在继承关系，解决了第一次设计的问题，同时因为已经对Fly接口进行实现，Duck类不在需要自己实现Fly接口，解决了第二次设计的问题）

代码（Duck抽象类，定义接口类型）：

同时，增加set方法（可动态改变）

在Duck的子类中，对接口进行实例化

总结：

1. 将应用中可能需要变化的地方独立出来，不要和那些不需要变化的代码混在一起 {

　　如例子中的fly方法，因为存在变化性，就不要和类似于display方法这样的固定刚需方法混在一起

}

2. 针对接口编程，而不是针对实现编程 {

　　如例子中，不是由Duck类来实现Fly接口，而是我们新建FlyXX类来实现Fly接口，这样，鸭子的行为作为独立类，而不是由Duck父类来具体实现（设计1），或者继承某个接口后由子类实现（设计2），这样鸭子的行为就不会被绑死在Duck类上

}

3. 多用组合，少用继承 {

　　在例子中，组合即是Duck类与Fly等行为类结合起来使用，使用组合建立系统能有很大的弹性，更可以在运行时动态改变行为

}

4. 上述例子的改写过程，用的便是策略模式 {

　　策略模式定义了一系列的算法（例子中的Fly和Quack行为都属于算法），分别封装起来，让他们之间可以互相替换，使算法的变化独立于使用算法的客户（例子中Duck类与Fly等行为类将不会因为继承关系互相影响）

}

当然，策略模式也有缺点：

1. 客户端需要知道所有策略类

2. 策略模式会生成很多策略类

原文：http://www.cnblogs.com/X-Spider/p/5371282.html