重构（Refactoring）技巧读书笔记 之二
General Refactoring Tips, Part 2
本文继续《重构（Refactoring）技巧读书笔记 之一》，重构的确是未来软件工程师需要掌握的一项技能。目前一些支持.Net的重构工具，如ReSharper for VS.Net v1.0、Borland Together for VS.Net v2.0和VS.Net 2005等，只能支持一些有限的、比较简单的重构策略。大量的重构策略需要软件工程师清晰的了解，人工为主，运用重构工具辅助进行。（注：本文重构策略的名称及其大部分内容来自《重构－改善既有代码的设计》一书，Martin Fowler 著，侯捷等译）。
下面的内容延续上一节的内容，其中提及的一些代码坏味道（Bad Smell in Codes）及其重构策略相对而言要比较麻烦一些。
一、代码坏味道（Bad Smell in Codes）及其重构策略
5．Divergent Change（发散式变化）
现象：当某个Class因为外部条件的变化或者客户提出新的功能要求等时，每次修改要求我们更新Class中不同的方法。不过这种情况只有在事后才能觉察到，因为修改都是在事后发生的么（废话）。
重构策略：将每次因同一条件变化，而需要同时修改的若干方法通过Extract Class将它们提炼到一个新Class中。实现目标是：每次变化需要修改的方法都在单一的Class中，并且这个新的Class内所有的方法都应该与这个变化相关。
6．Shotgun Surgery（霰弹式修改）
现象：当外部条件发生变化时，每次需要修改多个Class来适应这些变化，影响到很多地方。就像霰弹一样，发散到多个地方。
重构策略：使用Move Method和Move Field将Class中需要修改的方法及成员变量移植到同一个Class中。如果没有合适的Class，则创建一个新Class。实现目标是，将需要修改的地方集中到一个Class中进行处理。
比较Divergent Change（发散式变化）和Shotgun Surgery（霰弹式修改）：
前者指一个Class受到多种外部变化的影响。而后者指一种变化需要影响到多个Class需要修改。都是需要修理的对象。
7．Feature Envy（依恋情结）
现象：Class中某些方法“身在曹营心在汉”，没有安心使用Class中的成员变量，而需要大量访问另外Class中的成员变量。这样就违反了对象技术的基本定义：将数据和操作行为（方法）包装在一起。
重构策略：使用Move Method将这些方法移动到对应的Class中，以化解其“相思之苦”，让其牵手。
8．Data Clumps（数据泥团）
现象：指一些相同数据项目（Data Items），如Class成员变量和方法中参数列表等，在多个Class中多次出现，并且这些数据项目有其内在的联系。
重构策略：通过使用Introduce Parameter Object（创建新的参数对象取代这些参数）或Preserve Whole Object（使用已存在的对象取代这些参数），实现使用对象代替Class成员变量和方法中参数列表，清除数据泥团，使代码简洁，也提高维护性和易读性。
9．Primitive Obsession（基本型偏执狂）
现象：在Class中看到大量的基本型数据项目（Data Item），如Employee类中有大量的数据成员，Employee#, FirstName, MiddleName, LastName, Address, State, City, Street, Zip, OfficePhone, CellPhone, Email……等等。
重构策略：使用Extract Class（提炼新类）或Preserve Whole Object（使用已存在的对象取代这些参数），实现使用对象代替基本型数据项目（Data Item）。如上述Employee类中就可分别提炼出EmployeeName和EmployeeContact两个新类。
10．Switch Statements（Switch语句）
现象：同样的Switch语句出现在不同的方法或不同的Class中，这样当需要增加新的CASE分支或者修改CASE分支内语句时，就必须找到所有的地方，然后进行修改。这样，就比较麻烦了。
重构策略：(1)首先采用Extract Method将Switch语句提炼到一个独立的函数。
(2)然后以Move Method搬移到需要多态性（Polymorphism）的Superclass里面或者是构建一个新的Superclass。
(3)进一步使用Replace Type Code with Subclasses或者Replace Type Code with State/Strategy。这步就比较麻烦些，不过记住如下基本规则：这里一般有3个Class分别为Source Class、Superclass和Subclass。
Source Class：
l 使用Self Encapsulate Field，将Type Code成员变量封装起来，也就是建立对应的Setter/Getter函数。
l 在Source Class中增加一个Superclass类型的成员变量，用来存放Subclass实例对象。
l 在Source Class中的Getter函数，通过调用Superclass的Abstract Query函数来完成。
l 在Source Class中的Setter函数，通过调用Superclass中的Static工厂化方法来获取合适的Subclass实例对象。
Superclass：
新建的一个Class（注：就是上面通过Move Method搬移生成的Superclass），根据Type Code的用途命名该Class，作为Superclass。
l 在Superclass中建立一个Abstract Query函数，用来获取Subclass的Type Code。
l 在Superclass中创建Static工厂化方法生产对应的Subclass对象，这里会存在一个Switch语句（不要再动脑筋来重构这个Switch语句了，这个Switch语句不会在多处重复存在，并且这里用于决定创建何种Subclass对象，这是完全可以接受的）。
Subclass：
l 根据每一个Switch/Type分支，建立对应的Subclass，并且Subclass的命名可以参考Switch/Type分支的命名。
l 在每一个Subclass中重载Superclass的Abstract Query函数，返回特定的Type Code。
(4)现在Superclass仍然存在Switch分支，是时候轮到Replace Conditional with Polymorphism上场了。具体而言，就是在每一个Subclass中创建重载方法（注：该方法是Superclass中含有Switch语句的方法），并将Superclass中Switch语句对应的Case分支剪切过来。最后将Superclass中该方法初象化Abstract，并清除Switch语句及其所有的Case分支。
这样就完成了整个重构过程，这个比较麻烦。
注：并不是一看到Switch语句及CASE分支，就马上/偏执狂采用上述重构策略进行重构，画蛇添足或吃亏不讨好（个人观点）。一般而言，只有看到多处出现相同的Switch语句时，才应该考虑进行重构。
References:
1, Rickie, 重构（Refactoring）技巧读书笔记 之一