设计模式[去粗取精]--策略模式

    Design Pattern的重要性众人皆知，小弟学习之有些许时日，在此将自己所想所思记录之。

    大家多多指点，小弟感激不尽。

 

    策略模式 (Strategy)

 

    策略模式展现了设计模式中最基本、最常用，同时也最重要的一些原则：

 

    原则 1. 封装变化

    代码中总是会有一些 “将来可能会变化” 或 “需要在运行时动态切换” 的片段，将这些变化的片段与那些不变的片段分离开来，多数情况下是十分必要的。否则很容易使代码变得臃肿、难以维护。

 

    How to do：

    将某一类“变化”的操作（其实就是方法，这些方法会有各种各样的版本的实现，这种多样性从一种动态发展的角度去看就称其为变化）封装成接口，各种具体的操作就可以实现这个接口得到扩展。这个接口和它的实现类，称作一个算法簇。你可以有好多算法簇。这样不变的部分，就和变化的部分分开了，且变化的部分也有了良好的组织，以备不变的部分来调用。

 

    原则 2. 多用组合，少用继承

    继承并不总是好的，考虑这种情况：它强行的将父类的特性附加给了那些不需要这些特性的子类们，使得子类还要编写额外的代码来屏蔽这些特性。

 

    How to do:

    我们将变化的部分(b类) 和 不变的部分(A类)分离了，那他们两者又如何联系呢。一般来讲，都是由不变的部分 调用 变化的部分提供的服务，所以，我们需要在 A 中声明一个 b 的变量，同时为了能够在任何时候都有改变 b 的实现的能力，最好给 b 提供 getter 和 setter 方法。

 

    少用继承，并不是不用继承。需要用继承的地方自然还是要用。如：A类 中某些属性或方法是 A 这类事务所特有的、统一不变的，那么就把这些属性或方法放在 A 类中，而  A 类的各个子类所特有的属性和方法，自然就可以写在各个子类中了。

 

    原则 3.针对接口编程，不针对实现编程

    把实现类的类型作为引用变量类型，那么变量只能引用这一种类型，若是换作实现类的接口类型，那么就可以随时更换实现了。

 

    How to do：

    在步骤2中，将算法簇的接口做为 A 类中引用的类型，在使用时，只要将需要的实现类的实例set进去就可以了。