重构方法

一、重新组织函数

1、Extract Method （提炼函数）

你有一段代码可以被组织在一起并独立出来。将这段代码放进一个独立函数，并让函数名称解释该函数的用途。

2、Inline Method （内联函数）

一个函数调用的本体与名称同样清楚易懂。在函数调用点插入函数体，然后移除该函数。

3、Inline Temp （内联临时变量）

你有一个临时变量，只被一个简单表达式赋值一次，而它妨碍了其他重构手法。将所有对该变量的引用动作，，替换为对它赋值的那个表达式自身

4、Replace Temp with Query （以查询取代临时变量）

你的程序以一个临时变量保存某一个表达式的运算效果。将这个表达式提炼到一个独立函数中。将这个临时变量的所有引用点替换为对新函数的调用。此后，新函数就可以被其他函数调用。

5、Introduce Explaining Variable （引入解释性变量）

你有一个复杂的表达式。将该复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途。

6、Split Temporary Variable （分解临时变量）

你的程序有某个临时变量被赋值超过一次，它既不是循环变量，也不被用于收集计算结果。针对每次赋值，创造一个独立、对应的临时变量

7、Remove Assignments to Parameters （移除对参数的赋值）

代码对一个 参数赋值。以一个临时变量取代该参数的位置。    

8、Replace Method with Method Object （以函数对象取代函数）

你有一个大型函数，其中对局部变量的使用使你无法采用 Extract Method （提炼函数）。将这个大型函数放进一个单独对象中，如此一来局部变量就成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。

9、Substitute Algorithm （替换算法）

你想要把某个算法替换为另一个更清晰地算法。将函数本体替换为另一个算法。   

二、在对象之间搬移特性

10、Move Method （搬移函数）

你的程序中，有个函数与其所驻类之外的另一个类进行更多的交流：调用后者，或被后者调用。在该函数最常用引用的类中建立一个有着类似行为的新函数。将旧函数编程一个单纯的委托函数，或是将旧函数完全移除。

11、Move Field （搬移字段）

你的程序中，某个字段被其所驻类之外的另一个类更多的用到。在目标类建立一个新字段，修改源字段的所有用户，令它们改用新字段。

12、Extract Class （提炼类）

某个类做了应该由2个类做的事。建立一个新类，将相关的字段和函数从旧类搬移到新类。

13、Inline Class （将类内联化）

某个类没有做太多事情。将这个类的所有特性搬移到另一个类中，然后移除原类。

14、Hide Delegate （隐藏委托关系）

客户通过一个委托类在调用另一个对象。在服务类上建立客户所需的所有函数，用以隐藏委托关系。

15、Remove Middle Man （移除中间人）

某个类做了过多的简单委托动作。让客户直接调用受托类。

16、Introduce Foreign Method （引入外加函数）

你需要为提供服务的类增加一个函数，但你无法修改这个类。在客户类中建立一个函数，并以第一参数形式传入一个服务类实例。

如果客户类只使用这项功能一次，那么额外编码工作没什么大不了，甚至可能根本不需要原本提供服务的那个类。然而，如果你需要多次使用这个函数，就得不断重复这些代码。重复代码是软件万恶之源。这些重复代码应该被抽出来放进一个函数中。进行本项重构时，如果你以外加函数实现一项功能，那就是一个明确信号：这个函数原本应该在提供服务的类中实现。

       如果你发现自己为一个服务类建立了大量外加函数，或者发现有许多类需要同样的外加函数，就不应该再使用本项重构，而应该使用 Introduce Local Extension （引入本地扩展）。

       但是不要忘记：外加函数终归是权宜之计。如果有可能，你仍然应该将这些函数搬移到它们的理想家园。如果由于代码所有权的原因使你无法做这样的搬移，就把外加函数交给服务类的提供者，请他帮你在服务类中实现这个函数。

 

17、Introduce Local Extension （引入本地扩展）

你需要为服务类提供一些额外函数，但你无法修改这个类。建立一个新类，使它包含这些额外函数。让这个扩展品成为源类的子类或包装类。

所谓本地扩展是一个独立的类，但也是被扩展类的字类型：它提供源类的一切特性，同时额外添加新特性。在任何使用源类的地方，你都可以使用本地扩展取而代之。

   使用本地扩展使你得以坚持：函数和数据应该被统一封装“的原则。如果你一直把本该放在扩展类中的代码零散的放置于其他类中，最终只会让其他这些类变得过分复杂，并使得其他函数难以被复用。

   在子类和包装类之间做选择时，首选子类。因为这样的工作量比较少。制作子类的最大障碍在于，它必须在对象创建期实施。如果可以接管对象创建过程，那当然没问题；但如果你想在对象创建之后再使用本地扩展，就有问题了。此时，子类化方案还必须产生一个子类对象，这种情况下，如果有其他对象引用了旧对象，我们就同时有2个对象保存了原数据。如果原数据是不可修改的，那也没问题。可以放心进行复制；但如果原数据允许修改，问题就来了，因为一个修改动作无法同时改变2份副本。这时候就必须改用包装类。使用包装类时，对本地扩展的修改会波及原对象，反之亦然。

 

三、重新组织数据

18、Self Encapsulate Field （自封装字段）

你直接访问一个字段，但与字段之间的耦合关系逐渐变得笨拙。为这个字段建立取值/设值函数，并且只以这些函数来访问字段。

19、Replace Data Value with Object （以对象取代数据值）

你有一个数据项，需要与其他数据和行为一起使用才有意义。将数据项变成对象。

20、Change Value to Reference （将值对象改为引用对象）

从一个类中衍生出许多彼此相等的实例，希望将它们替换为一个对象。将这个值对象变成引用对象。

21、Change Reference to Value （将引用对象改为值对象）

你有一个引用对象，很小且不可变，而且不易管理。将它变成一个值对象。

22、Replace Array with Object （以对象取代数组）

你有一个数组，其中的元素各自代表不同的东西。以对象替换数组，对于数组中的每个元素，以一个字段来表示。

23、Duplicate Observed Data （复制“被监视数据”）

你有一些领域数据置身于GUI控件中，而领域函数需要访问这些数据。将该数据复制到一个领域对象中。建立一个Observer模式，用以同步领域对象和GUI对象内的重复数据。

24、Change Unidirectional Association to Bidirectional （将单向关联改为双向关联）

2个类都需要使用对方特性，但其间只有1条单向连接。添加1个反向指针，并使修改函数能够同时更新2条连接。

25、Change Bidirectional Association to Unidirectional （将双向关联改为单向关联）

2个类之间有双向关联，但其中一个类如今不再需要另一个类的特性。去除不必要的关联。

26、Replace Magic Number with SymBolic Constant （以字面常量取代魔法数）

你有一个字面数值，带有特别含义。创建一个常量，根据其意义为它命名，并将上述的字面数值替换为这个常量。

27、Encapsulated Field （封装字段）

你的类中存在一个public字段。将它声明为private，并且提供相应的访问函数。

28、Encapsulated Collection （封装集合）

有一个函数返回一个集合。让这个函数返回该集合的一个只读副本，并在这个类中提供添加/移除集合元素的函数。

29、Replace Record with Data Class （以数据类取代记录）

你需要面对传统编程环境中的记录结构。为该记录创建一个“哑”数据对象。

动机：记录型结构是许多编程环境的共同性质。有一些理由使它们被带进面向对象程序之中：你可能面对的是一个遗留程序，也可能需要通过一个传统API来与记录结构交流，或是处理从数据库读出的记录。这些时候你就有必要创建一个接口类，用以处理这些外来数据。最简单的做法就是先建立一个看起来类似外部记录的类，以便日后将某些字段和函数搬移到这个类中。一个不太常见但非常令人注目的情况是：数组中的每个位置上的元素都有特定含义，这种情况下应该使用 Replace Array with Object （以对象取代数组）。

做法：1、新建一个类，表示这个记录。

       2、对应记录中的每一项数据，在新建的类中建立对应的一个private字段。并提供相应的取值/设值函数。

       现在，你拥有了一个“哑”数据对象，这个对象现在还没有任何有用的行为，但是更进一步的重构会解决这个问题。

 

30、Replace Type Code with Class （以类取代类型码）

类之中有一个数值类型码，但它并不影响类的行为。以一个新的类替换该数值类型码。

31、Replace Type Code with Subclass （以子类取代类型码）

你有一个不可变的类型码，它会影响类的行为。以子类取代这个类型码。

32、Replace Type Code with State/Strategy （以状态/策略取代类型码）

你有一个类型码，它会影响类的行为，但你无法提供继承手法消除它。以状态对象取代类型码。

33、Replace Subclass with Field （以字段取代子类）

你的各个子类的唯一差别只在“返回常量数据”的函数身上。修改这些函数，使它们返回超类中的某个（新增）只读，然后销毁子类。

四、简化条件表达式

34、Decompose Conditional （分解条件表达式）

你有一个复杂的条件语句。从if、then、else三个段落中分别提炼出独立函数。

35、Consolidate Conditional Expression （合并条件表达式）

你有一系列条件测试，都得到相同结果。将这些测试合并为一个条件表达式，并将这个条件表达式提炼为一个独立函数。

动机：有时你会发现这样一串条件检查：检查条件各不相同，最终行为却一致。如果发现这种情况，就应该使用“逻辑或”和“逻辑与”将它们合并为一个条件表达式。

36、Consolidate Duplicate Conditional Fragments （合并重复的条件片段）

在条件表达式的每个分支上有着相同的一段代码。将这段重复代码移到条件表达式之外。

动机：一组条件表达式的所有分支都执行了相同的某段代码。你应该将这段代码搬移到表达式外面。这样，代码才能更清楚地表明哪些东西随条件变化而变化、哪些东西保持不变。

 

37、Remove Control Flag （移除控制标记）

在一系列布尔表达式中，某个变量带有“控制标记’的作用。以break或return语句取代控制标记。

动机：在一系列条件表达式中，常常会看到用以判断何时停止条件检查的控制标记。这样的标记带来的麻烦超过了它所带来的便利。人们之所以会使用这样的控制标记，因为结构化编程原则告诉他们：每个子程序只能有一个入口和出口。“单一出口“原则会让你在代码中加入让人讨厌的控制标记，大大降低条件表达式的可读性。这就是编程语言提供break和continue语句的原因：用它们跳出复杂的条件语句。去掉控制标记所产生的效果往往让你大吃一惊：条件语句真正的用途会清晰得多。

 

38、Replace Nested Conditional with Guard Clauses （以卫语句取代嵌套条件表达式）

函数中的条件逻辑使人难以看清正常的执行途径。使用卫语句表现所有特殊情况。

动机：条件表达式通常有2种表现形式。第一：所有分支都属于正常行为。第二：条件表达式提供的答案中只有一种是正常行为，其他都是不常见的情况。

       这2类条件表达式有不同的用途。如果2条分支都是正常行为，就应该使用形如if…..else…..的条件表达式；如果某个条件极其罕见，就应该单独检查该条件，并在该条件为真时立刻从函数中返回。这样的单独检查常常被称为“卫语句”。

 

39、Replace Conditional with Polymorphism （以多态取代条件表达式）

你手上一个条件表达式，它根据对象类型的不同而选择不同的行为。将这个条件表达式的每个分支放进一个子类的覆写函数中，然后将原始函数声明为抽象函数。

40、Introduce Null Object （引入Null 对象）

你需要再三检查某对象是否为null。将null值替换为null对象。

动机：多态的最根本好处在于：你不必再向对象询问“你是什么类型”而后根据得到的答案调用对象的某个行为-你只管调用该行为就是了，其他的一切多态机制会为你安排妥当。当某个字段内容是null时，多态可扮演另一个较不直观的用途。

 

41、Introduce Assertion （引入断言）

某一段代码需要对程序状态做出某种假设。以断言明确表现这种假设。

五、简化函数调用

42、Rename Method （函数改名）

函数的名称未能揭示函数的用途。修改函数名称。

43、Add Parameter （添加参数）

某个函数需要从调用端得到更多信息。为此函数添加一个对象参数，让该对象带进函数所需信息。

44、Remove Parameter （移除参数）

函数本体不再需要某个函数。将该参数去除。

45、Separate Query form Modifier （将查询函数和修改函数分离）

某个函数既返回对象状态值，又修改对象状态。建立2个不同的函数，其中一个负责查询，另一个负责修改。

46、Parameterize Method （令函数携带参数）

若干函数做了类似的工作，但在函数本体中却包含了不同的值。建立一个单一函数，以参数表达那些不同的值。

47、Replace Parameter with Explicit Methods （以明确函数取代参数）

你有一个函数，其中完全取决于参数值而采取不同香味。针对该参数的每个可能值，建立一个独立函数。

48、Preserve Whole Object （保持对象完整）

你从某个对象中取出若干值，将它们作为某一次函数调用时的参数。改为传递整个对象。

49、Replace Parameter with Methods （以函数取代参数）

对象调用某个函数，并将所得结果作为参数，传递给另一个函数。而接受该参数的函数本身也能够调用前一个函数。让参数接受者去除该项参数，并直接调用前一个函数。

50、Introduce Parameter Object （引入参数对象）

某些参数总是很自然地同时出现。以一个对象取代这些参数。

51、Remove Setting Method （移除设置函数）

类中的某个字段应该在对象创建时被设值，然后就不再改变。去掉该字段的所有设值函数。

52、Hide Method （隐藏函数）

有一个函数，从来没有被其他任何类用到。将这个函数修改为private。

53、Replace Constructor with Factory Method （以工厂函数取代构造函数）

你希望在创建对象时不仅仅是做简单的建构动作。将构造函数替换为工厂函数。

54、Encapsulate Downcast （封装向下转型）

某个函数返回的对象，需要由函数调用者执行向下转型（downcast）。将向下转型动作移到函数中。

动机：向下转型也许是无法避免的，但你仍然应该尽可能少做。如果你的某个函数返回一个值，并且你知道所返回的对象类型比函数签名所昭告的更特化，你便是在函数用户身上强加了非必要的工作。这种情况下你不应该要求用户承担向下转型的责任，应该尽量为他们提供准确的类型。

 

55、Replace Error Code with Exception （以异常取代错误码）

某个函数返回一个特定的代码，用以表示某种错误情况。改用异常。

56、Replace Exception with Test （以测试取代异常）

面对一个调用者可以预先检查的条件，你抛出一个异常。修改调用者，使它在调用函数之前先做检查。

六、处理概括关系

57、Pull Up Field （字段上移）

2个子类拥有相同的字段。将该字段移至超类。

58、Pull Up Method （方法上移）

有些函数，在各个子类中产生完全相同的结果。将该函数移至超类。

59、Pull Up Constructor Body （构造函数本体上移）

你在各个子类中拥有一些构造函数，它们的本体几乎完全一致。在超类中新建一个构造函数，并在子类构造函数中调用它。

60、push down Method （函数下移）

超类中的某个函数只与部分子类有关。将这个函数移到相关的那些子类去。

61、push down field （字段下移）

超类中的某个字段只被部分子类用到，将这个字段移到需要它的那些子类去。

62、Extract Subclass （提炼子类）

类中的某些特性只被某些实例用到。新建一个子类，将上面所说的那一部分特性移到子类中。

63、Extract Superclass （提炼超类）

2个类有相似特性。为这2个类建立一个超类，将相同特性移至超类。

64、Extract Interface （提炼接口）

若干客户使用类接口中的同一子集，或者2个类的接口部分相同。将相同的子集提炼到一个独立接口中。

动机：类之间彼此互用的方式有若干种。“使用一个类”通常意味着用到该类的所有责任区。另一种情况是，某一组客户只使用类责任区中的一个特定子集。再一种情况是，这个类需要与所有协助处理某些特定请求的类合作。

       对于后2种情况，将真正用到的这部分责任分离出来通常很有意义，因为这样可以使系统的用法更清晰，同时也更容易看清系统的责任划分。如果新的类需要支持上述子集，也比较能够看清子集内有些什么东西。

       在许多面向对象语言中，这种责任划分是通过多继承来实现的。在c#中可以运用接口来诏示并实现上述需求。

      Extract Subclass （提炼子类）和Extract Interface （提炼接口）之间有些相似之处。Extract Interface （提炼接口）只能提炼共通接口，不能提炼共通代码。使用Extract Interface （提炼接口）可能造成难闻的“重复”坏味道，幸而你可以运用Extract Class（提炼类）先把共通行为放进一个组件中，然后将工作委托给该组件，从而解决这个问题。如果有不少共通行为，Extract Superclass （提炼超类）会比较简单，但是每个类只能有一个超类。

       如果某个类在不同环境下扮演截然不同的角色，使用接口就是个好主意。你可以针对每个角色以Extract Interface （提炼接口）提炼出相应接口。另一种可以用Extract Interface （提炼接口）的情况是：你想要描述一个类的外部依赖接口。如果你打算将来加入其它种类的服务对象。只需要求它们实现这个接口即可。

 

65、Collapse Hierarch （折叠继承体系）

超类和子类之间无太大区别。将它们和为一体。

66、Form Template Method （塑造模板函数）

你有一些子类，其中相应的某些函数以相同的顺序执行类似的操作，但各个操作的细节不同。将这些操作分别放进独立的函数中，并保持它们都有相同的签名，于是原函数也就变得相同了，然后将原函数上移至超类。

67、Replace Inheritance with Delegation （以委托取代继承）

某个子类只使用超类接口中的一部分，或是根本不需要继承而来的数据。在子类中新建一个字段用以保存超类；调整子类函数，令它改而委托超类；然后去掉2者之间的继承关系。

68、Replace Delegation with Inheritance （以继承取代委托）

你在2个类之间使用委托关系，并经常为整个接口编写许多极简单的委托函数。让委托类继承受托类。

动机：本项重构与ReplaceInheritance with Delegation （以委托取代继承）恰恰相反。如果你发现自己需要受托类中的所有函数，并且花费很大力气编写所有极简单的委托函数，本重构可以帮助你轻松回头使用继承。

       2条告诫需牢记与心：首先，如果你并没有使用受托类的所有函数，那么就不应该使用Replace Delegation with Inheritance （以继承取代委托）,因为子类应该总是遵循超类的接口。如果过多的委托函数让你烦心，你有别的选择：你可以通过 Remove Middle Man （移除中间人）让客户端自己调用受托函数，也可以使用Extract Superclass （提炼超类）将2个类接口相同的部分提炼到超类中,然后让2个类都继承这个新的超类；你还可以用类似手法使用ExtractSuperclass （提炼超类）。

       另一种需要当心的情况是：受托对象被不止一个其他对象共享，而且受托对象是可变的。在这种情况下，你就不能将委托关系替换为继承关系，因为这样就无法再共享数据了。数据共享是必须由受托对象承担的一种责任，你无法把它转给继承关系。如果受托对象是不可变的，数据共享就不成问题，因为你大可放心地复制对象。