设计模式之策略模式 ——整理自《HeadFirst设计模式》等

HeadFirst使用模式最好的方法是：“把模型装进脑子里，然后在你的设计和已有应用中，寻找何处可以使用它们。”以往是代码复用，现在是经验复用。

 

1.       不加思考的在基类中加上某一方法会导致所有继承此基类的派生类中都具有此方法的统一实现方式。第一种解决方法是在派生类中对基类的这一方法进行覆盖重载转化，然而这种方式会导致软件后期维护繁琐，因为要检查所有可能被覆盖的方法。第二种解决方法是：利用接口编程，凡是需要有此方法之处就实现此接口，然而这种方法会使重复代码增加而增多，并且会随着子类的增加而呈几何级增加。

2.       好的期望，如果能有一种建立软件的方法，好让我们可以用一种对既有的代码影响最小的方式来修改软件该有多好。我们就可以花较少的时间重做代码，而多让程序员去做更多更酷的事。

3.       不管你在何处工作，构建些什么，用何种编程语言，伴随着你的软件开发一个不变的真理是不管你当初软件设计的多好，一段时间之后总是需要成长与改变，否则软件就会“死亡”

4.       设计原则之一：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。(这几乎是每一个设计模式背后的精神所在。)

1.       设计原则之二：针对接口编程，而不是针对实现编程。

某类的行为被放在分开的类中，此类专门提供某行为接口的实现，这样原有类就不必要再知道行为的实现细节了，只需要调用对应接口即可，此举将大大方便程序的拓展性编程。

 

2.       以前的做法是，行为来自基类的具体实现，或是继承某个接口并由子类自行实现而来。这两种做法都是依赖于“实现”，我们被实现绑的死死的，没办法更改行为。而利用这种原则的好处在于，特定的具体行为编写在实现了易变的行为基类中了。

3.       永远不要先把系统做出来之后，再试图观察有哪些地方需要改变，然后再回头去把这些地方分离、封装。通常在你的设计系统时，预先考虑到有哪些地方未来可能需要变化，于是提前在代码中加入这些弹性。你会发现，原则与模式可以应用在软件开发生命周期的任何阶段。

4.       类不仅仅可以代表“东西”也可以代表行为。在OO系统中，类既可以代表状态（实例变量）又有方法。

5.       尽量将基类的行为委托给另一个相关类去处理，而不是使用基类中本身的方法去处理。

6.       设计原则之三：多用组合，少用继承。 为什么？

使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以“在运行时动态的改变行为”，只要组合的行为对象符合正确的接口标准即可。

 

7.       好处：使用组合建立系统具有很大的弹性，不仅可以将算法族封装成类，更可以在运行时动态的改变行为，只要组合的行为对象符合正确的接口标准即可。

8.       设计原则之一、二、三之综合：策略模式

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