策略模式

设计模式是可复用的解决方法。

书中举了这样一个例子：

图1.png

这是一个利用继承复用代码的例子，把子类相同的行为放在基类，达到复用的效果。再利用抽象，让子类实现自己的行为。

图2.png

由于业务需要我们给基类添加了一个行为fly(),所有的子类都继承了这个行为。如果我们再添加一个子类，但并不需要fly()，可以重载这个方法，函数体中不做任何事，可是再添加一个子类同样是不同的需求，之前的方法不能完美的解决这样的问题，因为永远不变的是改变。显然用继承来解决代码复用的问题会带来很多负面的影响：代码在多个子类重复，运行时行为不容易改变，改变基类就会导致所有子类跟着一起改变，很难知道类所有的行为。
解决这一问题的设计原则是：找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。把会变化的部分取出并封装起来，以便以后可以轻易地改动或扩充此部分，而不影响不需要变化的其他部分，使系统变得更有弹性。对应以上的例子，应该把Duck类中变化的两个行为quack()和fly()独立并封装，这样解决了代码复用的问题，再有新的行为也可以以这种方式把行为独立出来，避免了改变基类导致所有子类都受影响的问题，还可以在类中加入设定行为的方法，这就解决了运行时不能动态的改变的问题。
具体来说，怎样抽取并封装呢？我们可以利用针对接口编程，而不是针对实现编程。

图3.png

这里的针对接口编程就是针对超类编程，核心是利用多态，执行时会根据实际情况 执行到真正的行为。
【不要刻意的把所有类都设计成接口，不变的可以放在基类用于继承，只需把变化的设计成接口，他们的目的都为了『复用』，原则与模式可以应用在软件开发生命周期的任何阶段。】
我们已经把变化的行为抽取出来，现在要利用『委托』把行为整合进Duck类中

public class  Duck {

   QuackBehavior mQuackBehavior; 

   FlyBehavior  mFlyBehavior;

   public void performQuack(){

       mQuackBehavior.quack();

   } 

       
      public void performFly(){

       mFlyBehavior.fly();

   }

}
public class MallardDuck extends Duck{

   public MallardDuck(){

       mQuackBehavior = new Quack();

       mFlyBehavior = new FlyWithWings();

   }
}

在基类中加入两个接口类型的实例变量，Duck类只知道FlyBehavior可以执行行为fly，并不关心是如何fly，至于具体的实现放在了子类处理，这里Duck把原本自己实现的行为委托给行为类。<br />
这里引出了第三个设计原则：多用组合，少用继承。Duck的行为是通过适当的对象『组合』来的，而不是继承来的。<br />

策略模式定义：定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

设计模式告诉我们如何组织类和对象以解决某种问题。