Strategy模式

1.背景：

  短期的抄近路，可能会在长期导致问题严重复杂化。一些原因使许多项目只关心处理眼前的紧迫需求，却不顾将来的维护。

  软件开发的两个错误的极端：分析瘫痪和放任自流。

 

2.处理概念上完全相同的不同实现有下面几种方案：

   (1)复制粘贴：忽略了重用对象的可能性。

   (2)用一个变量指定各种情况：可能会出现分支蔓延，降低可测试性。

   (3)使用函数指针或委托：无法维持每个对象的状态，使用受限。

   (4)继承：继承层次无法轻松应对多方面发生变化，采用多次特化会产生巨型继承。

 

3.”考虑变化的设计“方式：

   不是要准确预测出变化性质，而是假设变化将出现，并尝试预测其出现的位置。

   针对接口编程，而不是针对实现编程。

   优先使用对象组合，而不是类继承。

   意图是能够在互相独立的类中包含变化，从而充许未来发生变化，而不影响原有的代码。

   找出变化的概念，并封装（在一个单独的类中）。使不改变设计，即可以改变实现。对变化的概念进行封装，这是许多设计模式的主题。

 

3.策略模式定义：

   将对算法的选择和算法的实现相分离，允许根据上下文进行选择。

   策略模式以下列几条原则为基础：对象都具有职责；这些职责不同的具体实现是通过多态的使用完成的；概念上相同的算法具有多个不同的实现，需要进行管理。

4.实现：

    策略模式是摒弃了2.2和2.3的方案，而采用将其使用的算法封装在一个抽象类中，在某一时刻能够互换的使用其中之一。

    让使用算法的类(Context)包含一个抽象类(Strategy)，由一个配置对象负责选择Strategy的具体实现，并传给Context。

    也可以让Context类组合配置对象，自己负责生成具体策略对象。

    这个配置对象可能是一个工厂类，可以采用简单工厂模式；也可以使用反射技术实现，“反射反射，程序员的快乐”。

    Strategy类处在Context类之外，它所需要的信息要么传递给它，要么以某种其它形式获得。

    Strategy模式还简化了单元测试。

   

5.提高 了内聚度；使职责的转移更容易。

6.一些措施尽量减少类的数据

   concrete 具体的

   如果可以控制所有的ConcreteStrategy类，可以在Strategy抽象类的头文件中写ConcreteStrategy类的头文件，同时在Strategy源文件中写ConcreteStrategy类的实现代码。

   如果使用的是java，可以在Strategy类中使用内部类包含ConcreteStrategy类。