设计模式之策略模式——极客学院学习笔记

变化部分它的行为相互之间是可以替换的，而且不同变化部分是相互独立的（如：飞行与叫声）。正是因为这样，可以使用策略模式抽象出接口和行为簇。行为簇中行为对象可以相互替换，不同行为簇之间相互没有关联。我们要多用组合，少用继承。虽然使用继承，代码的复用很好了，但是有些子类不需要这些功能，区域性不好控制，但如果将实现代码不放在超类中，而是放在子类中，则相同的行为在需要的子类中都要实现一遍，它的复用性就不好了。

在超类中加入了功能，子类中都继承了这个方法，但是有些子类不需要这个功能。所以继承的问题：对类的局部改动，尤其超类的局部改动，会影响其他部分，影响会有溢出效应。

1.继续尝试用OO原理来解决，覆盖

如果类很多，工作量就很大了。

如果将飞行功能不放到超类里面，需要的去实现，不需要的不去实现，看似可以，但是代码的复用性降低了。比如说10种鸭子都会飞，而且飞得一样，每一种鸭子都要实现而且是相同的方法，代码的复用性降低了。实现上虽然对某些子类方便，但是却影响了其他子类，有溢出效应。

2.如果有石头鸭子，不会飞，不会叫，不会游泳，所以所有的方法都要覆盖掉。

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

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

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

2）鸭子哪些功能是会根据新需求变化的？

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

一般在子类的构造方法中将子类行为实例化。

将行为进行抽象，抽象成接口。

对象类型是Duck超类，而不是GreenHeadDuck等，这样的好处是这样调用的时候直接调用超类的方法，此时到子类中去把行为对象等于方法，这样就屏蔽了子类的具体实现，因为定义为超类它只调用超类里的方式，而具体子类怎么实现不用管。这样的话红、绿鸭的差别性就不用考虑了。

行为接口-->行为簇-->具体的行为不是在类里面实现了，而是直接new一个行为簇实现