Refactoring to Patterns 读书笔记（三）

应用 Strategy 模式替代条件逻辑结构

Martin Fowler 在他的 Refactoring 一书中写道：“One of the most common areas of complexity in a program lies in complex conditional logic.”

我们通常使用条件逻辑结构决定程序中的哪个算法代码会被执行，而业务相关的算法经常会发生变化，例如新增一项业务就可能需要添加一段对应的算法代码。当需要处理的业务不断增多的时候，程序体中相关的条件逻辑结构也会随之膨胀，从而使程序体变得复杂难懂起来。

Strategy 模式正好可以用来帮助处理这种情况。

如果需要重构的代码是基于继承结构的，那么可以考虑应用 Refactoring 中的“Replace Conditional with Polymorphism”方法对之重构。倘若其尚未组织成继承结构的代码，但是其条件逻辑结构是基于类型代码（type code）的，则可以继续考虑使用 Refactoring 一书中的“Replace Type Code with subclasses”。如果不存在上面所说的情况，那么采用对象组合（object-compositional）方式的 Strategy 模式来进行重构，会更好一些。

如果采用 Strategy 模式的话，就需要考虑 strategy 对象中的算法如何获取其所需的数据。通常来说，有两个方法：其一是将 context 对象委托给 strategy 对象，strategy 对象通过回调来获取数据；其二是直接通过参数将数据传给 strategy 对象。两种方法各有利弊。对于第一种方案，坏处是 context 类中的某些方法为此需要暴露出来（设置为 public 的），从而破坏了信息隐藏的原则；好处则是当 context 中添加了 public 的方法的时候，strategy 则立即可以使用它们。在 Java 环境中，可以考虑只将 context 类中相应方法的访问控制符设置为 package；在 C++ 环境中，可以考虑将 strategy 类设置为 context 类的友元。对于第二种方案，坏处是可能某些具体的 strategy 类会被迫接受其不需要的参数；好处则是这样做的后果是使得 context 类和 strategy 类之间的耦合性最小。

最后需要注意的是，如果 context 类和 strategy 类的组合不太多的话，最好是能够将之与客户代码隔离开来，也就是说让客户代码不必显式地实例化 strategy 对象，再显式地将该对象交给一个 context 对象。采用“用 Factory 模式封装类”的方法，即可以达到以上目标。