由于之前看的容易忘记，因此特记录下来，以便学习总结与更好理解，该系列博文也是第一次记录，所有有好多不完善之处请见谅与留言指出，如果有幸大家看到该博文，希望报以参考目的看浏览，如有错误之处，谢谢大家指出与留言。

思路：

1、模拟鸭子项目

2、项目的新需求

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

4、用策略模式来新需求解决

5、重新设计模拟鸭子项目

6、总结策略模式定义

一、模拟鸭子项目

1、从项目"模拟鸭子游戏"开始 2、从OO的角度设计这个项目,鸭子超类，扩展超类：
public abstract class Duck {    
public void Quack() {    
    System.out.println("~~gaga~~");
}
public abstract void display();
public void swim() {    
    System.out.println("~~im swim~~");
}
}1、GreenHeadDuck继承Duck ：
public class GreenHeadDuck extends Duck {    
@Override    
public void display() {    
      System.out.println("**GreenHead**");
}
}
2、同理可有RedHeadDuck等

二、项目的新需求

1、应对新的需求，看看这个设计的可扩展性 1）添加会飞的鸭子 2、OO思维里的继承方式解决方案是：
public abstract class Duck {
         ...;
         public void Fly() {    
         System.out.println("~~im fly~~");
}
}；

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

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

1、继续尝试用OO原理来解决，覆盖：
public class GreenHeadDuck extends Duck {
...；
public void Fly() {
System.out.println("~~no fly~~");//把会飞的工程覆盖掉，实现不让他飞。}
}
这个导致，后面几十个鸭子不没有这个功能，不会飞，那么他们的都要去实现。工作量大，而且重复劳动。有人说:会飞功能不放在超类中，放在抽象函数，让子类去实现，这样需要的就去实现，不需要的不需要实现，但是这样，代码复用性却不高，比如：有10种鸭子都会飞，而且飞的方式都一样，所以实现代码都是一样的，代码复用性降低，对某些子类方便，但对其他有些子类确有影响。
2、又有新需求，石头鸭子，填坑：
public class StoneDuck extends Duck {
.... }；比如石头鸭子，既不会飞，也不会叫，那么所有代码都要去覆盖。
所以：超类挖的一个坑，每个子类都要来填，增加工作量，复杂度O(N^2)。不是好的设计方式

四、用策略模式来新需求解决

策略模式：属于对象的行为模式。其用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得他们可以相互替换。策略模式使得算法可以在不影响客户端的情况下发生变化。

所以遇到问题首先要分析项目的变化与不变化部分，对项目中的问题都可以按此思路。

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

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

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

1、接口：
1）public interface FlyBehavior
{    
void fly();}
2）public interface QuackBehavior
{    
void quack();};
3）抽象接口好处：新增行为简单，行为类更好的复用，组合更方便。既有继承带来的复用好处，没
有继承带来的坏处。

五、重新设计模拟鸭子项目

1、重新设计的鸭子项目：
public abstract class Duck {    
FlyBehavior mFlyBehavior;
QuackBehavior mQuackBehavior;
public Duck() { }
public void Fly() {    
mFlyBehavior.fly();
}
public void Quack() {    
mQuackBehavior.quack();
}
public abstract void display();
}

六、总结策略模式定义

1、绿头鸭、石头鸭：

在超累的基础上，子类直接在构造函数中，去new一个行为族，在用行为族中的行为去实现。

public class GreenHeadDuck extends Duck {
public GreenHeadDuck() {
mFlyBehavior = new GoodFlyBehavior();
mQuackBehavior = new GaGaQuackBehavior();
}
@Override
public void display() {...}
}

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

七、策略模式总结与注意点

1、分析项目中变化部分与不变部分（方法论）——》这个方法论不仅是策略模式中才可以用的，用来分析项目中变法的何不变化的，变化的就可以怎么来抽取替换。而且变化的抽离出来的行为族，行为族之间是可以来相互替换的。

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

3、如果找不到适用的模式怎么办？

（1）.可能对项目分析的不够透彻。

（2）.存在特殊的项目无法用设计模式，那么就只能用原始的面向对象的特性（其实设计模式也是基于oop总结提炼出来的精华所在）

八、策略模式中的设计原则

1、开闭原则（Open-Closed Principle，缩写为OCP）

  1）一个软件实体应当**对扩展****开放**(例如对抽象层的扩展)，**对修改****关闭**(例如对抽象层的修改)。即在设计一个模块的时候，应**当使这个模块可以在不被修改的前提下被扩展**。
  2）**开闭原则的关键，在于抽象**。策略模式，是开闭原则的一个极好的应用范例。

2、里氏替换原则（Liskov Substitution Principle，缩写为LSP）

 1）里氏替换原则里一个软件实体如果使用的是**一个基类的话，那么一定适用于其子类**，而且它根本不能察觉到基类对象和子类对象的区别。比如，假设有两个类，一个是Base类，一个是Derived类，并且Derived类是Base类的子类。**那么一个方法如果可以接受一个基类对象b的话：method1(Base b)，那么它必然可以接受一个子类对象d，也即可以有method1(d)。反之，则不一定成立**。
 2）**里氏替换原则讲的是基类与子类的关系**。只有当这种关系存在时，里氏替换关系才存在，反之则不存在。
 3）**策略模式之所以可行的基础**便是**里氏替换原则**：策略模式要求所有的**策略对象都是可以互换**的，因此它们都必须是一个抽象策略角色的子类。**在客户端则仅知道抽象策略角色类型，虽然变量的真实类型可以是任何一个具体策略角色的实例。**