### 重构的记录格式 介绍重构时，我采用一种标准格式。每个重构手法都有如下五个部分： - 首先是名称（name)。建造一个重构词汇表，名称是很重要的。这个名称也就是我将在本书其他地方使用的名称。 - 名称之后是一个简短概要。（summary），简单介绍此一重构手法的适用情景，以及它所做的事情。这部分可以帮助你更快找到你所需要的重构手法。 - 动机（motivation），为你介绍「为什么需要这个重构』和「什么情况下不该使用这个重构」。 - 作法（mechanics），简明扼要地一步一步介绍如何进行此一重构。 - 范例（examples），以一个十分简单的例子说明此重构手法如何运作。 「概要」（summary）包括三个部分：(1)一个简短文句，介绍这个重构能够帮助的问题；(2)一段简短陈述，介绍你应该做的事；(3)一幅速写图，简单展现重构前后示例；有时候我展示代码，有时候我展示统一建模语言（UML）图。哪一种形式能更好呈现该重构的本质，我就使用该种形式（本书所有UML图都根据实现观点（implementation perspective）而画[Fowler,UML]。〕如果你以前见过这一重构手法，那么速写图能够让你迅速了解这一重构的概况；如果你不曾见过这个重构，可能就需要浏览整个范例，才能得到较好的认识。 「作法」（mechanics）出自我自己的笔记。这些笔记是为了让我在一段时间不做某项重构之后还能记得怎么做。它们也颇为简洁，通常不会解释「为什么要这么做那么做」。我会在「范例」（examples）给出更多解释。这么一来「作法」就成了简短的笔记。如果你知道该使用哪个重构，但记不清具体步骤，可以参考「作法」部分（至少我是这么使用它们的）；如果你初次使用某个重构，可能「作法」对你还不够，你还需要阅读「范例」。 撰写「作法」的时候，我尽量将重构的每个步骤都写得简短。我强调安全的重构方式，所以应该采用非常小的步骤，并且在每个步骤之后进行测试。真正工作时我通常会采用比这里介绍的「婴儿学步」稍大些的步骤，然而一旦遇上臭虫，我就会撤销上一步，换用比较小的步骤。这些步骤还包含一些特定状况的参考，所以它们也有检验表（checklist）的作用；我自己经常忘掉这些该做的事情。 「范例」（examples）像是简单而有趣的教科书。我使用这些范例是为了帮助解释重构的基本要素，最大限度地避免其他枝节，所以我希望你能原谅其中的简化工作(它们当然不是优秀商用对象设计的适当例子）。不过我敢肯定你一定能在你手上那些更复杂的情况中使用它们。某些十分简单的重构干脆没有范例，因为我觉得为它们加上一个范例不会有多大意义。 更明确地说，加上「范例」仅仅是为了阐释当时讨论的重构手法。通常那些代码最终仍有其他问题，但修正那些问题需要用到其他重构手法。某些情况下数个重构经常被一并运用，这时候我会把某个范例拿到另一个重构中继续使用。大部分时候，一个范例只为一项重构而设计，这么做是为了让每一项重构手法自给自足（self-contained），因为这份重构名录的首要目的还是作为参考工具。 这些例子不会告诉你「如何设计一个"employee"对象或一个"order"对象」。这些例子的存在纯粹只是为了说明重构，除此之外别无用途。例如你会发现，我在这些例子中用double数据来表示货币金额。我之所以这样做，只是为了让例子简单一些，因为「以什么形式表示金额」对于重构自身并不重要。在真正的商用软件中，我强烈建议你不要以double表现金额。如果真要表示货币金额,我会使用Quantity模式[Fowler,AP]。 撰写本书之际，商业开发中使用得最多的是Java1.1，所以我的大多数例子也以Java1.1写就，这从我对群集（collections）的使用就可以明显看出来。本书即将完成之时，Java2己经正式发布。但我不觉得有必要修改所有这些例子，因为对重构来说，群集（collections）也是次要的。但是有些重构手法，例如Encapsulate Collection，在Java1.2中有所不同。这时候我会同时解释Java2和Java1.1。 修改后的代码可能被埋没在未修改的代码中，难以一眼看出，所以我使用粗体（boldface code）突显修改过的代码。但我并没有对所有修改过的代码都使用粗体字，因为一旦修改过的代码太多，全都粗体反而不能突显重点。