设计模式学习笔记之策略模式

参考：《Head first 设计模式》，部分引用来自 http://www.cnblogs.com/colinsong/archive/2009/03/02/1401723.html

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

The Strategy Pattern defines a family of algorithms,encapsulates each one,and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it

设计原则：

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

优点：

　　1、 简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。
　　2、 避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。
        3、 遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。

缺点：
　　1、 因为每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。
      2、 在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的Context对象。（这本身没有解除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由Context来承担，这就最大化的减轻了客户端的压力。）

理解：

书本说的Java中接口（Interface）有点类似于Objective-C中的协议（Protocol）的意味，注意到“针对接口编程”真正的意思是“针对超类型（supertype）编程”，在C++中可以使用由纯虚函数组成的类实现。

        设计方法其实就是使用组合代替继承，“HAS-A(有一个) 可能比IS-A(是一个)更好”，并且有助于实现封装的高内聚，低耦合。

        例如 我们要封装一个【按钮】控件类，这个类 HAS-A（有一个）画外观行为，输出文字行为，还能响应点击事件，对于不同按钮，每个行为都不一定相同，例如有些按钮外观是圆形的，有些按钮可以没有文字。如果 在基类 Button 中把这些行为实现了，或者要求其子类实现（C++用纯虚函数，Java，C#用接口，Objective-C用协议的必选方法），这些做法都是依赖于“实现”，我们都被绑得死死的，没办法更改行为。策略模式中的设计是，在子类中使用接口所表示的行为，实际的实现不会被绑定在子类中。这里的Button类添加三个成员：drawButtonView,drawButtonText,buttonClicked,那么Button想要画外观只要让 drawButtonView 对象去画就行了，例如一个按钮，在普通情况下都是方形，那么在Button中可以给 drawButtonView赋值一个DrawRectButton实例对象，当一个新的按钮需要实现圆形按钮，那么只需要重新给drawButtonView成员赋值一个DrawRoundButton的实例对象就行了，并且我们能在运行时通过多态动态地给它指定不同的drawButtonView行为。

PS，如果是C++中，DrawButtonView 应该是DrawRectButton,DrawRoundButton的超类