本节书摘来自异步社区《重构与模式（修订版）》一书中的第1章1.5节重构与模式，作者【美】Joshua Kerievsky，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.5 重构与模式重构与模式（修订版）我观察了自己和同事们在许多项目中重构的对象和方式。在使用《重构》[F]一书中描述的许多重构方法时，我们还发现模式有助于改进设计。很多次我们都是通过重构实现模式，或者通过趋向模式进行重构，小心翼翼地避免产生过分灵活或者过度复杂的方案。
深入研究了应用“模式导向的重构”的动机之后，我发现它和“实现低层次重构”的一般动机是一样的：减少或去除重复的地方，简化复杂之处，使代码更好地表达其意图。
但是，如果只学习某个设计模式的一部分，很容易忽视这种动机。例如，《设计模式》[DP] 中的所有模式都包含一个名为“意图”的部分。《设计模式》的作者们是这样描述意图的：“意图是回答下列问题的简单陈述：设计模式是做什么的？它的基本原理和意图是什么？它解决的是什么样的特定设计问题？”[DP, 6]话虽如此，但是许多设计模式的“意图”部分只是在说明模式解决的主要问题。相反，更多的注意力放在了“模式是做什么的”之上。
我们来看两个例子。
Template Method（模板方法）的意图
定义一个操作中算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以在不改变算法结构的情况下，重定义该算法的某些特定步骤。[DP, 325]
State（状态）的意图
允许一个对象在其内部状态改变时改变自己的行为。对象看起来似乎修改了自己的类。[DP, 315]这些意图描述并没有说明Template Method 有助于减少或者去掉类层次中各个子类里相似方法中的重复代码，也没有说明State模式有助于简化复杂的有条件的状态改变逻辑。如果程序员学习了一个设计模式的所有部分，尤其是“适用性”部分，他们将了解到该模式所要解决的问题是什么。
但是，在设计中使用《设计模式》一书时，许多程序员，包括我自己，都是通过阅读模式的“意图”部分，确定这个模式是否适合当前的情况。这种选择模式的方法的有效性不如将设计问题与模式能够解决的问题进行比对。为什么呢？因为模式之所以存在，就是为了解决问题，所以要了解在某种情况下模式是否真的有所帮助，必须理解它们有助于解决什么问题。
重构方面的文献似乎比模式方面的文献更关注具体的设计问题。开始学习某个重构时，你会在书的第一页看到重构有助于解决何种问题。本书给出的“模式导向的重构”目录直接延续了《重构》一书中所开创的工作，其目的是帮助读者了解模式有助于解决哪些具体的问题。
本书架设了模式和重构之间的桥梁，但是，其实《设计模式》一书的作者们在其皇皇巨著的“结论”一章已经提到了这两者之间的联系：
我们的设计模式记录了许多重构产生的设计结构。……设计模式为你的重构提供了目标。[DP, 354]
Martin Fowler在《重构》一书的开始也有类似的说明：
模式和重构之间存在着天然联系。模式是你想到达的目的地，而重构则是从其他地方抵达这个目的地的条条道路。[F, 107]
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
相关资源：重构与模式(中文版).pdf