### Extract Hierarchy（提炼继承体系） 你有某个class 做了太多（过多〕工作，其中一部分工作是以大量条件式完成的。 建立继承体系，以一个subclass 表示一种特殊情况。  **动机（Motivation）** 在渐进式设计过程中，常常会有这样的情况：一开始设计者只想「以一个class 实 现一个概念」；但随着设计方案的演化，最后却可能「一个class 实现了两个、三 个乃至十个不同的概念」。一开始，你建立了这个简单的class ；数天或数周之后， 你可能发现：只要加入一个标记（flag）和一两个测试，就可以在另一个环境下使用这个class ；一个月之后你又发现了另一个这样的机会；一年之后，这个class 就完全一团糟了：标记变量和条件式遍布各处。 当你遇到这种「瑞士小刀般」的class ，不但能够开瓶开罐、砍小树枝、在演示文稿会上打出激光强调重点……（简直无所不能），你就需要一个好策略（亦即本项重构、将它的各个功能梳理并分开。不过，请注意，只有当条件逻辑（conditional logic）在对象的整个生命期间保持不变，本重构所导入的策略才适用。否则你可能必须在分离各种状况之前先使用Extract Class。 Extract Hierarchy 是一项大型重构，如果你一天之内不足以完成它，不要因此失去勇气。将一个极度混乱的设计方案梳理出来，可能需要数周甚至数月的时间。 你可以先进行本重构中的一些简易步骤，稍微休息一下，再花数天编写一些明显有生产力的代码。当你领悟到更多东西，再回来继续本项重构的其他步骤——这些步骤将因为你的领悟而显得更加简单明了。 **作法（Mechanics）** 我们为你准备了两组重构作法。第一种情况是：你无法确定变异（variations）应该是些什么（也就是说你无法确定原始class 中该有哪些条件逻辑〕。这时候你希望每次一小步地前进： - 鉴别出一种变异（variation）。 - 如果这种变异可能在对象生命期内发生变化，就运用Extract Class 将它提炼为一个独立的class 。 - 针对这种变异，新建一个subclass ，并对原始class 实施Replace Constructor with Factory Method。再修改factory method，令它返回适当的（相应的）subclass 实体。 - 将含有条件逻辑的函数，一次一个，遂一拷贝到subclass ，然后在明确情况下 （注：对subclass 明确，对superclass 不明确！），简化这些函数。 - 如有必要隔离函数中的「条件逻辑」和「非条件逻辑」，可对superclass 实施Extract Method。 - 重复上述过程，将所有变异（variations；特殊情况）都分离出来，直到可以将superclass 声明为抽象类（abstract class）为止。 - 删除superclass 中的那些「被所有subclasses 覆写」的函数（的本体），并将 它声明为抽象函数（abstract class）。 如果你非常清楚原始class 会有哪些变异（variations），可以使用另一种作法： - 针对原始class 的每一种变异（variation）建立一个subclass 。 - 使用Replace Constructor with Factory Method 将原始过class 的构造函数转变成factory method ，并令它针对每一种变异返回适当的subclass 实体。 - 如果原始class 中的各种变异是以type code 标示，先使用 Replace Type Code with Subclasses ；如果那些变异在对象生命期间会改变， 请使用Replace Type Code with State/Strategy。 - 针对带有条件逻辑的函数，实施 Replace Conditional with Polymorphism。如果并非整个函数的行为有所变化，而只是函数一部分有所变化，请先运用 Extract Method 将变化部分和不变部分隔开来。 **范例：（Example）** 这里所举的例子是「变异并不明朗」的情况。你可以在 Replace Type Code with Subclasses、Replace Type Code with State/Strategy 和 Replace Conditional with Polymorphism 等重构结果之上，验证「变异已经明朗」的情况下如何使用本项重构。 我们以一个电费计算程序为例。这个程序有两个classes ：表示「消费者」的Customer 和表示「计费方案」的BillingScheme，如图12.11。  图12.11 Customer 和BillingScheme BillingScheme 使用大量条件逻辑来计算不同情况（变异）下的费用：冬季和夏季的电价不同，私宅用电、小型企业用电、社会救济（包括残障人士）用电的价格也不同。这些复杂的逻辑导致BillingScheme 变得复杂。 第一个步骤是，提炼出条件逻辑中经常出现的某种变异性。本例之中可能是「视用户是否为残障人士」而发生的变化。用于标示这种情况的可能是Customer、 BillingScheme 或其他地方的一个标记变量（flag）。 我们针对这种变异建立一个subclass 。为了使用这个subclass ，我们需要确保它被建立并且被使用。因此我们需要处理BillingScheme 构造函数：首先对它实施 Replace Constructor with Factory Method，然后在所得的factory method 中为残障 人士增加一个条件子句，使它在适当时候返回一个DisablityBillingScheme对象。 然后，我们需要观察BillingScheme 的其他函数，寻找那些随着「用户是否为残障人士」而变化的行为。createBill() 就是这样一个函数，因此我们将它拷贝到subclass （图 12,12）。  图12.12 为「残障人士」添加一个subclass 现在，我们需要检查subclass 中的createBill() 函数。由于现在我们可以肯定该 消费者是残障人士，因此可以简化这个函数。所以下列代码： ~~~ if (disabilityScheme()) doSomething ~~~ 可以变成： ~~~ doSomething ~~~ 如果规定在「残障人士用电」和「企业用电」之间只能择一，那么我们的方案就可以避免在BusinessBillingScheme 中出现任何条件代码。 实施本项重构时，我们希望将「可能变化」和「始终不变」的部分分开，为此我们可以使用 Extract Method 和Decompose Conditional。本例将对BillingScheme 各函数实施这两项重构，直到「是否为残障人士」的所有判断都得到了适当处理。然后我们再以相同过程处理他种变异（例如「社会救济用电」）。 然而，当我们处理第二种变异时，我们应该观察「社会救济用电」与「残障人士用 电」有何不同。我们希望能够为不同的变异（特殊情况）建立起这般函数：有着相同意图，但针对不同的变异性（特殊情况）釆取不同的实际作为（译注：这就是Template Method）。例如上述两种变异情况下的税额计算可能不同。我们希望确保两个subclasses 中的相应函数有相同的签名式（signature）。这可能意味我们必须修改DisablityBillingScheme，使得以将subclasses 整理一番。通常我们发现，面对更多变异时，这种「相仿之中略带变化」的函数（similar and varying methods patterns）会使整个系统结构趋于稳定，使我们更容易添加后续更多变异。