1.1 策略模式(Strategic Pattern)

> 模拟鸭子项目

> 项目的新需求

> 用OO原则解决新需求的不足

> 用策略模式来新需求解决

> 重新设计模式鸭子项目

1.1 模拟鸭子项目

1.1.1 从项目“模拟鸭子游戏”开始

1.1.2 从OO的角度设计这个项目，鸭子超类，扩展超类：

1、GreenHeadDuck继承Duck：

2、同理可有RedHeadDuck等

3、StimulateDuck运行

1.2 项目的新需求

1.2.1 应对新的需求，看看这个设计的可扩展性

1）添加会飞的鸭子(野鸭等会飞的行为)

1.2.2 OO思维里的继承方式解决方案是：

public abstract class Duck {

……；

public void Fly(){

System.out.println("~~im fly~~")；

}

}

继承的问题：对类的局部改动，尤其超类的局部改动，会影响其他部分。影响会有溢出效应 问题来了，这个Fly让所有子类都会废了，这是不科学的。

1.3 用OO原则解决新需求的不足

1.3.1 继续尝试用OO原理来解决，覆盖：

public class GreenHeadDuck extends Duck {

……；

public void Fly() {

System.out.println("~~no fly~~");

}

}

1.3.2 又有新需求，石头鸭子，填坑：

public class StoneDuck extendsDuck{

……；

}

超类挖的一个坑，每个子类都要来填，增加工作量，复杂度O（N^2）。不是好的设计方式

1.4 用策略模式来新需求解决

1.4.1 需要新的设计方式，应对项目的扩展性，降低复杂度：

1）分析项目变化与不变部分，提取变化部分，抽象成接口+实现；

2）鸭子那些功能是会根据新需求变化的？叫声、飞行……

1.4.2 接口：

1）public interface FlyBehavior{

void fly();

}

2）public interface QuackBehavior {

void quack();

}

3）好处：新增行为简单，行为类更好的复用，组合更方便。既有继承带来的复用好处，没有挖坑

1.5 重新设计模拟鸭子项目

1.5.1 重新设计的鸭子项目：

1.5.2 策略模式：分别封装行为接口，实现算法族，超类里放行为接口对象，子类 里具体设定行为对象。原则就是：分离变化部分，封装接口，基于接口编写各种功能。此模式让行为算法的变化独立于算法的使用者。

注意点：

1、分析项目中变化部分与不变部分

2、多用组合少用继承;用行为类组合,而不是行为的继承。更有弹性

3、设计模式有没有相应的库直接使用？有些库或框架本省就用某种设计模式设计的

4、如果找不到适用的模式这么办？ 答：还不够熟悉