《重构——改善既有代码的设计》读书笔记

一、重构原则

1、重构的两个定义

      重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本

      重构(动词):使用一系列重构手法,在不改变软件可观察行为的前提下,调整其结构

2、重构与设计

       重构与设计彼此互补,重构带来更简单的设计,同时又不损失灵活性,这也降低了设计过程的难度,减轻了设计压力。我们并不需要一开始就有灵活且复杂的设计,而是建立可运行的最简化系统。然后,就交给重构去做。

       软件与机器的最大区别在于软件的可塑性更强,完全是思想产品。机械工程可以画工程图,做充分的设计,再施工。软件工程更适合通过迭代不断进化的方式进行。

二、代码的坏味道

1、Duplicated Code (重复代码)

        如果在一个以上的地点看到相同的程序结构,那么设法将它们合二为一,程序会变得更好。

2、Long Method (过长方法)

        方法越长越难理解,方法越短复用可能性越大。

3、Large Class (过大的类)

        过大的类难以理解和维护,容易造成代码重复、混乱。

4、Long Parameter List (过长的参数列表)

        将对象传递给方法,让方法从对象中获得自己需要的参数,胜过面面俱到地传递方法用到的参数。

5、Divergent Change (发散式变化)

        改变一个类,可能影响多个软件行为。(引起类变化的因素应该只能有一个才合适)。

6、Shotgun Surgery (散弹式修改)

        与发散式变化相反,修改一个软件行为,需要修改多处代码。或者说针对某一外部变化,需要修改多个类。

7、Feature Envy (依恋情节)

        方法对某个类的兴趣高于对自己应该所属类的兴趣。(如果哪个类拥有最多被此方法使用的数据,就把该方法与这些数据摆在一起)。

注:strategy 和 visitor模式,最根本的原则是:将总是一起变化的东西放在一块儿。数据与引用这些数据的行为总是一起变化的。

8、Data Clump(数据泥团)

        多个类中有相同的字段、许多函数签名中有相同的参数,(将相互依赖、关联的那些数据封装在一个类中,即组成一个新对象,才合适)

9、Primitive Obsession(基本类型偏执)

        对象新手通常偏执于基本类型,而非小对象(其实,用小对象代替基本类型是更好的选择,例如结合数据和币种形成的小对象money类、由起始值和结束值组成的range类,还有时间、邮编、电话号码等)。

10、Switch Statements (switch 惊悚现身)

        在面向对象程序中出现switch语句,特别是相同的switch判断出现在不同的地点。(在OOP中要少用switch语句,使用OOP中的多态概念可为此类问题带来优雅的解决方法)

11、Parallel Inheritance Hierarchies (平行继承体系)

       是散弹式修改的特殊情况,每当为某个类添加一个子类,必须也为另外一个类相应地增加一个子类。(解决方法:让一个继承体系的实例引用另一个继承体系的实例,最终将一个继承体系(引用端的)消弭于无形)

12、Lazy Class (冗赘类 )

       几乎没用的类。(对于几乎没用的类就改为内部类)

13、Speculative Generality (夸夸其谈未来性)

      也就是过度设计,以各式各样的钩子和特殊情况来处理一些非必要的事情。(如果用不到就不做,如果某个抽象类没太大用处,就折叠继承层次,如果方法的参数未被使用,就去掉该参数,如果方法名带有多余的抽象意味,就重命名)。

14、Temporary Field (令人迷惑的暂时字段)

      类内某个实例变量仅为某种特殊情况而设(可以将该特殊字段,连同所有相关的代码都放在一个新类中)

15、Message Chains (过度耦合的消息链)

      方法的调用层次过多(通过Hide Delegate消除)

16、Middle Man (中间人)

     过度委托,类中的多数方法都“不干实事”。(移除中间人,直接和真正负责的对象打交道)

17、Inappropriate Intimacy (狎昵关系)

      两个类的联系过于紧密,职责界限不清晰(类与类之间的职责界面要清晰)

18、Alternative Classes with Different Interfaces (异曲同工的类)

      两个方法的做同一件事,但签名不同(方法的功能要唯一)

19、Incomplete Library Class (不完美的库类)

     类库的设计不够好,而我们不能修改其中的类和方法(引入外加函数或引入本地扩展来解决)

20、Data Class (纯稚的数据类)

     纯稚的数据类是指仅拥有字段和访问这些字段的方法的类。这样的类用处不大(可以为这样的类添加调用、操作这些字段的行为方法)。

21、Refused Bequest(被拒绝的遗赠)

      子类不想或不需要继承超类的方法和数据(这意味着继承体系设计错误,传统做法是:将超类中不需要的字段和方法下移到其中一个子类,特殊情况也可以通过委托代替继承来做到这点)

22、Comments (过多的注释)

      注释的存在,通常是代码糟糕不容易理解的结果,(如果方法需要注释,建议改写方法名,如果为了说明某些系统的要求规格,可以引入断言)。

三、构建测试体系

      重构前,要构建自测试代码。

四、重构手法

      基本的重构技巧——小步前进、频繁测试

      设计模式为重构行为提供了目标,模式是你希望到达的目标,重构是到达之路。

------------------------------------------------------------重新组织函数-------------------------------------------------------------

1、Extract Method(提炼方法)

     如果你有一段代码可以被组织在一起并独立出来,就将这段代码放进一个独立方法中,并让方法名解释该方法的用途。

技巧:使用Replace Temp with Query来消除临时变量

2、Inline Method (内联方法)

     一个方法的本体与名称同样清晰易懂,就在方法调用点插入方法本体,然后移除该方法。(注意,检查方法,确定不具有多态性,才能这么做)

3、Inline Temp( 内联临时变量)

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

4、Replace Temp with Query (以查询取代临时变量)

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

5、Introduce Explaining Variable (引入解释性变量)

     如果你有一个复杂的表达式,就将该复杂表达式(或其中的一部分)的结果放进一个临时变量,以变量名称来解释表达式用途

6、Split Temporary Variable (分解临时变量)

      如果程序中某个临时变量被赋值超过一次,它既不是循环变量,也不被用于收集计算结果。针对每次赋值,创造一个独立、对应的临时变量(临时变量的职责要单一)。

7、Remove Assignments to Parameters (移除对方法的赋值)

      如果代码对一个参数进行赋值,就以一个临时变量取代该参数的位置。(说Java只是按值传参,这里的值是基本类型和对象引用(指针))。

8、Replace Method with Method Object (以方法对象取代方法)

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

9、Substitute Algorithm (替换算法)

      如果你想要把某个算法替换为另一个更清晰的算法,就将方法本体替换为另一个算法。(前提是已经尽可能地分解了原先方法)

------------------------------------------------------------在对象间搬移特性-------------------------------------------------------

10、Move Method (搬移方法)

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

11、Move Field (搬移字段)

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

12、Extract Class (提炼类)

      如果某个类做了应该由两个类做的事,就建立一个新类,将相关的字段和方法从旧类搬移到新类。

13、Inline Class (将类内联化)

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

14、Hide Delegate (隐藏“委托关系”)

      如果客户通过一个委托类来调用另一个对象,就在服务类上建立客户所需的所有方法,用以隐藏委托关系。这样委托关系改变就不会影响到客户端代码。

15、Remove Middle Man (移除中间人)

      如果某个类做了过多的简单委托动作,就让客户直接调用受托类。(与隐藏委托关系相反,实际中要保持平衡)

16、Introduce Foreign Method (引入外加方法)

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

17、Introduce Local Extension (引入本地扩展)

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

------------------------------------------------------------重新组织数据-------------------------------------------------------

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 (将单向关联改为双向关联)

     如果两个类都需要使用对方特性,但其间只有一条单向连接,就添加一个反向指针,并使修改函数能够同时更新两条连接。(这里的修改函数是指控制两个类连接关系的控制函数,它要位于单一引用的类中,即如果A类和B类是一对多的关系,就将修改函数放在A类中)。

25、Change Bidirectional Association to Unidirectional (将双向关联改为单向关联)

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

26、Replace Magic Number with Symbilic Constant (以字面常量取代魔法数)

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

27、Encapsulate Field (封装字段)

     如果你的类中存在一个public字段。就将它声明为private, 并提供相应的访问方法。(为了数据隐藏)

28、Encapsulate Collection (封装集合)

    如果有个方法返回一个集合,就让这个方法返回该集合的一个只读副本,并在这个类中提供添加/移除集合元素的方法。(即将集合成员隐藏,只暴露集合只读副本和集合元素给外面)

29、Replace Record with Data Class (以数据类取代记录)

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

30、Replace Type Code with Class (以类取代类型码)

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

31、Replace Type Code with Subclasses (以子类取代类型码)

    如果有一个不可变的类型码,它会影响类的行为,就以子类取代这个类型码。

32、Replace Type Code with State/Strategy (以State/Strategy取代类型码)

   如果你有一个类型码,它会影响类的行为,但你无法通过继承手法消除它,就以状态对象取代类型码。

33、Replace Subclass with Field(以字段取代子类)

   如果你的各个子类的唯一差别只在“返回常量数据”的函数身上。就修改这些函数,使它们返回超类中的某个(新增)字段,然后销毁子类。

------------------------------------------------------------简化条件表达式-------------------------------------------------------

34、Decompose Conditional (分解条件表达式)

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


35、Consolidate Conditional Expression(合并条件表达式)

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


36、Consolidate Duplicate Conditional Fragments (合并重复的条件片段)

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


37、Remove Control Flag (移除控制标记)

      如果在一系列布尔表达式中,某个变量带有“控制标记”(control flag)的作用,就以break语句或return语句取代控制标记。


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

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

注: 条件表达式通常有两种表现形式。第一种形式是:所有分支都属于正常行为。第二种形式则是:条件表达式提供的答案中只有一种是正常行为,其他都是不常见的情况

      如果两条分支都是正常行为,就应该使用形如if .. else... 的条件表达式,如果某个条件极其罕见,就应该单独检查该条件,并在该条件为真时立刻从函数中返回。这样的单独检查常常被称为“卫语句”(guard clauses)。


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

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

注:如果同一组条件表达式在程序许多地点出现,那么使用多态的收益是最大的。


40、Introduce Null Object (引入Null对象)
      如果你需要再三检查某对象是否为null,就将null值替换为null对象。
注:空对象有自己的方法来处理各种正常行为。空对象一定是常量,它的任何成分都不会发生变化,可以使用“单例模式”实现空对象。
        本质上,Null Object属于一个更大的模式:Special Case模式。所谓特例类(special case),也就是某个类的特殊情况,有着特殊的行为。特例类的价值是:它们降低你的“错误处理”开销。

41、Introduce Assertion (引入断言)
      如果某一段代码需要对程序状态做出某种假设,就以断言明确表现这种假设。
注:断言可以作为交流与调试的辅助。程序最后的成品往往将断言统统删除。

------------------------------------------------------------简化函数调用-------------------------------------------------------

42、Rename Method (函数改名)
       如果函数的名称未能揭示函数的用途,就修改函数名称。

43、Add Parameter (添加参数)
      如果某个函数需要从调用端得到更多信息。就为此函数添加一个对象参数,让该对象带进函数所需信息。

44、Remove Parameter(移除参数)
      如果函数本体不再需要某个参数,就将该参数去除。

45、Separate Query from Modifier (将查询函数和修改函数分离)
      如果某个函数既返回对象状态值,又修改对象状态。就建立两个不同的函数,其中一个负责查询,另一个负责修改。

46、Parameterize Method (令函数携带参数)
     如果若干函数做了类似的工作,但在函数本体中却包含了不同的值。就建立单一函数,以参数表达那些不同的值。

47、Replace Parameter with Explicit Methods(以明确函数取代参数)
     如果你有一个函数,其中完全取决于参数值而采取不同行为。就针对该参数的每一个可能值,建立一个独立函数。

48、Preserve Whole Object (保持对象完整)
     如果你从某个对象中取出若干值,将它们作为某一次函数调用时的参数。就改为传递整个对象。

49、Replace Parameter with Methods (以函数取代参数)
    如果对象调用某个函数,并将所得结果作为参数,传递给另一个函数。而接受该参数的函数本身也能够调用前一个函数。就让参数接受者去除该项参数,并直接调用前一个函数。

50、Intorduce Parameter Object (引入参数对象)
    如果某些参数总是很自然地同时出现,就以一个对象取代这些参数。

51、Remove Setting Method (移除设值函数)
    如果类中的某个字段应该在对象创建时被设值,然后就不再改变。就去掉该字段的所有设值函数。


52、Hide Mehtod(隐藏函数)
    如果有一个函数从来没有被其他任何类用到。就将这个函数修改为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 (字段上移)
     如果两个子类拥有相同的字段,就将该字段移至超类。

58、Pull Up Method (函数上移)
     如果有些函数,在各个子类中产生完全相同的结果,就将该函数移至超类。

59、Pull Up Constructor Body (构造函数本体上移)
     如果你在各个子类中拥有一些构造函数,它们的本体几乎完全一致。就在超类中新建一个构造函数,并在子类构造函数中调用它。

60、Push Down Method (函数下移)
    如果超类中的某个函数只与部分(而非全部)子类有关,就将这个函数移到相关的那些子类去。

61、Push Down Field (字段下移)
    如果超类中的某个字段只被部分(而非全部)子类用到,就将这个字段移到需要他的那些子类去。

62、Extract Subclass (提炼子类)
     如果类中的某些特性只被某些(而非全部)实例用到,就新建一个子类,将上面所说的那一部分特性移到子类中。

63、Extract Superclass (提炼超类)
     如果两个类有相似特性,就为这两个类建立一个超类,将相同特性移至超类。

64、Extract Interface (提炼接口)
     如果若干客户使用类接口中的同一子集,或者两个类的接口有部分相同,就将相同的子集提炼到一个独立接口中。

65、Collapse Hierarchy (折叠继承体系)
    如果超类和子类之间无太大区别,就将它们合为一体。

66、Form Template Method (塑造模板函数)
    如果你有一些子类,其中相应的某些函数以相同的顺序执行类似的操作,但各个操作的细节上有所不同。就将这些操作分别放进独立函数中,并保持它们都有相同的签名,于是原函数也就变得相同了。然后将原函数上移至超类。

67、Replace Inheritance with Delegation (以委托取代继承)
    如果某个子类只使用超类接口中的一部分,或是根本不需要继承而来的数据。就在子类中新建一个字段用以保存超类,调整子类函数,令它改而委托超类,然后去掉两者之间的继承关系。

68、Replace Delegation with Inheritance (以继承取代委托)
    如果你在两个类之间使用委托关系,并经常为整个接口编写许多极简单的委托函数。就让委托类继承受托类。

------------------------------------------------------------大型重构-------------------------------------------------------
    注:在进行大型重构时,有必要为整个开发团队建立共识,共识为修改指定了方向。
    对系统理解不够完整的设计决策,会很快将它们的影响蔓延到整个程序中。要根除这些影响,只有持续而无处不在的重构才有可能实现。

69、Tease Apart Inheritance (梳理并分解继承体系)
     如果某个继承体系同时承担两项责任,就建立两个继承体系,并通过委托关系让其中一个可以调用另一个。
    注:一个继承体系的职责应该尽可能单一(可以理解一个继承体系就是一个类),分离继承体系,让它们各自的超类之间建立委托关系。

70、Convert Procedural Design to Objects (将过程化设计转化为对象设计)
     如果你手上有一些传统过程化风格的代码,就将数据记录变成对象,将大块的行为分成小块,并将行为移入相关对象之中。

71、Separate Domain from Presentation (将领域和表述/显示分离)
     如果某些GUI类之中包含了领域逻辑。就将领域逻辑分离出来,为它们建立独立的领域类。

72、Extract Hierarchy (提炼继承体系)
     如果你有某个类做了太多工作,其中一部分工作是以大量条件表达式完成的。就建立继承体系,以一个子类表示一种特殊情况。

五、作者从重构中的领悟
     1、通过重新组织软件结构,重构使得设计思路更详尽明确。重构被用于开发框架、抽取可复用组件、使软件架构更清晰、使新功能的增加更容易。重构可以帮助你充分利用以前的投资,减少重复劳动,使程序更简洁有力。
     2、调整程序结构以使(短期内)添加新功能更容易。
     3、重构如何进行:随时挑选一个重构目标,没有把握时就停止前进,学习原路返回。
     4、项目的运行要始终保持在自己的手中,重构过程中如果发生项目整体失控的风险时(比如Bug不断,运行不稳定等)就应该立即停止重构,尽早找到原因,再决定是否继续重构。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值