重拾《重构-改善既有代码的设计》

什么是重构?

  • 是在不改变系统行为的前提下,对内部代码的重新组织,提高可理解性和降低修改成本。

为什么要重构?

  • 一个小修改牵涉到了多个地方,且这些点处于未知状态
  • 不易读懂代码(包括读懂自己1个月前的代码)
  • 新手修改代码上手慢,需要很久才能进行有信心的代码修改
  • 需求变化时,代码层面响应慢

什么时候需要重构?

  • 随时随地的重构,也就是从一开始就进行小范围的重构,就不至于时间久后没法平滑的重构了
  • 上面这句实际上是个方法论级别的,真实中,还是没办法判断什么时候要进行重构,于是换成:当代码中出现了坏味道时需要重构
  • 什么是坏味道:
    • 存在重复代码时
    • 函数体太长
    • 函数参数太长
    • 无法直观的看出代码逻辑
    • 类太大
    • 对一个常量存在了多个副本
    • 很多很多的if/else/switch语句
    • 类名、函数名、方法名不友好

重构与性能

  • 重构为先,调优其次
  • 重构能组织良好的结构,良好的结构能让调优工作更轻松

重新组织函数

  • Extract Method(提炼函数)
    • 当内部逻辑过分缠绕在一起时,需要将一些代码抽取到子函数中
  • Inline Method(内联函数)
    • 如果一个函数体很少,并且没有被其他函数使用到,就可以考虑将这个小函数内联到父函数中
  • Inline Temp(内联临时变量)
    • 如果一个变量只被使用到了1次,并且这个变量所代表的逻辑很少,此时可以考虑将这个临时变量所代表的逻辑直接拷贝到父函数中
  • Replace Temp with Query(以查询取代临时变量)
    • 如果去除了临时变量后,更加利于后续的重构改动,则会使用这种方法,将临时变量所代表的逻辑抽取成单独一个函数
    • 虽然对性能有影响,但是重构过去后,如果不是很严重的性能影响,则还是建议改成这样,因为重构过去后对后续重构更有利,更便于以后的重构
  • Introduce Explaining Variable(引入解释性变量)
    • 将逻辑碎片赋给命名友好的变量名,这样代码的可读性、理解性更强
  • Split Temporary variable(分解临时变量)
    • 一个逻辑目的只赋给一个临时变量,不要合用临时变量,如:
    • int temp=x+y;
    • //some logic to process temp varialbe
    • temp=getBase()+100;
    • //some logic to process the new temp varialbe
  • Remove Assignments to Parameters(移除对参数的赋值)
    • 禁止对传入参数的赋值,要用增加临时变量的方式来
  • Replace Method with method Object(以函数对象取代函数)
    • 针对大函数、逻辑复杂、局部变量多时
    • 思想是将这个函数独立成为一个类,在类中进行复杂逻辑的处理
  • Substitute Algorithm(替换算法)
    • 将函数内部的算法替换掉,比如:为了更高的效率或者更好的可理解性
    • 意图是提升效率或者可理解性
  • 大方向上都是让语义更加清晰

在对象之间搬移特性

  • Move Method(搬移函数)
    • 如果发现某个函数主要依赖于其他类的数据,则有必要将这个函数move到那个类中
  • Move Field(搬移字段)
    • 和上面的类似,至于是用哪个方法重构,需要看情况,比如看类的名称、职责定义
  • Extract Class(提炼类)
    • 当类包含大量函数、数据时,需要考虑拆分类
  • Inline Class(将类内联化)
    • 当某个类的职责不足以成为一个类时,考虑将这个类合并到其他类中
    • 比如这种情况发生在重构行为后,弱化了某个类的职责
  • Hide Delegate(隐藏“委托关系”)
    • 在server端隐藏某个类,这样客户端只需要知道1个类就能做逻辑操作,而不需要同时知道多个类才能进行逻辑操作了
  • Remove Middle Man(移除中间人)
    • 暴露更多的类来供客户端调用
    • “中间人”的移除与否比较难定,一般模块之间是尽量少暴露,模块内部要看情况而定
  • Introduce Foreign Method(引入外加函数)
    • 当提供的函数不能修改时,可以在客户端增加一个函数来包装这个目标函数,完成额外逻辑的插入转换
    • 这种额外函数不多
    • 用多了不好,最终需要合并到目标函数所在的server端
  • Introduce Local Extension(引入本地扩展)
    • 如果发生上述情况,并且扩展的比较多,则可以在客户端新建一个类,通过继承或者Wrapper的方式导入原始方法或类,进行额外方法、函数、逻辑的加工

重新组织数据

  • Self Encapsulate Field(自封装字段)
    • C#中使用属性来解决,不引用字段,要引用属性,以便在需要覆写变量值的时候嵌入逻辑
  • Replace Data Value with Object(以对象取代数据值)
    • 当对某个基元数据有更多的普遍常用功能时,需要将基元数据替换为对象类型,进而在这个对象中实现一些常用功能,方便调用方的调用
  • Change Value to Reference(将值对象改为引用对象)
    • 如果当前的某个值对象被多个地方用到,并且此时希望更改了一处后,其他地方的引用也跟着改变,此时需要将这个值对象转换为引用对象
    • 场景:项目刚开始时用了值对象,但是后来认为用引用类型更好,此时就需要转换
  • Change Reference to Value(将引用对象改为值对象)
    • 如果存在一个引用类型,而且这个引用类型较小,且不需要实现实例间的互相更改,此时可以把这个引用类型改为值类型,这样能保证这个对象的不可变性
  • Replace Array with Object(以对象取代数组)
    • 当一个数组被用在了传递对象属性用途时,可以采用类来替代这个数组
  • Duplicate Observed Data(复制“被监视的数据”)
    • 层与层之间的缠绕调用,没有划分好层导致的
    • 层与层之间通过DTO的方式进行传输数据
  • Change Unidirectional Association to Bidirectional(将单向关联改为双向关联)
    • 谨慎使用,尽量使单向关联
    • 需要在双方对象中加入维护对方的代码,如:Customer.AddOrder/Order.AddCustomer,都要成对出现
  • Change Bidirectional Association to Unidirectional(将双向关联改为单向关联)
    • 随着需求的演化,在某时间段,发现不需要双向关联了,此时用此法
  • Replace Magic Number with Symbolic Constant(以字面常量取代魔法数)
    • 字面量需要用const常量来替代
    • 如科学计算中某些具有特殊意义的数值,需要统一const引用
  • Encapsulate Field(封装字段)
    • 数据和行为被分开后,由于谁都可以引用public数据,因此不容易管理及修改
    • 如果不暴露数据,这样就能做到只在当前class中使用这些数据了
  • Encapsulate Collection(封装集合)
    • 默认的List<T> Collection<T> ArrayList暴露了太多内部逻辑,而且返回的对象能够被客户端修改,不利于隔离与封装
    • 自己写集合类,可以只暴露特定接口、返回对象新的拷贝,这样能解决恶意、无意的修改
  • Replace Record with Data Class(以数据类取代记录)
    • 将非对象化的平面数据类型(如:数组、传递过来的没有良好命名的属性等),重写成class,只有private属性的class
    • 目的只是为以后更进一步的重构做准备
  • Replace Type Code with Class(以类取代类型码)
    • Type Code:枚举、多个string、int变量,如:string Male="男性" string Female="女性"),诸如此类的标识
    • 将这个Type Code(包含了多个字段,但是只是区分不同的Type)抽象为一个Type Code类
    • 引用的相关地方也要做出更改
  • Replace Type Code with Subclasses(以子类取代类型码)
    • 用子类来标识,这样可以使用重写函数来解决一些行为上的变化
  • Replace Type Code with State/Strategy(以State/Strategy取代类型码)
    • 用状态、策略模式将变化部分抽取出来
  • Replace Subclass with Fields(以字段取代子类)
    • 如果子类中只是简单的返回一些常量,则可以将这些子类废除,压缩继承级别,将类型判断的逻辑写在父类的相应方法中

简化条件表达式

  • Decompose Conditional(分解条件表达式)
    • 往往逻辑比较复杂的地方,分支就较多
    • 一个分支中如果写了很多小段代码,也应该重构成更有语义的代码
    • 需要将分支重构为更加语义化,这样会提高可读性
  • Consolidate Conditional Expression(合并条件表达式)
    • 一般在函数入口出会检查参数有效性,如果写有多条if语句判断为无效,都返回false,则可以将这些都return false的判断抽取到一个单独函数中
    • 主函数中语义更加清晰
  • Consolidate Duplicate Conditional Fragments(合并重复的条件片段)
    • 如果在if/else分支中,每个分支的开始或者结束区域都使用了同样的代码,则提取到if/else外进行统一调用
  • Remove Control Flag(移除控制标记)
    • 用在循环中,去掉控制标记,比如bool found=false之类的控制标记,当找到时,直接return obj/return;
  • Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件表达式)
    • 把if/else以及嵌套的if/else改成平面写法,如:
    • if(xxx)return result+1;
    • if(yyy)return result+2;
    • if(zzz)return result+3;
    • return result+4;
  • Replace Conditional with Polymorphism(以多态取代条件表达式)
    • 用在有多个子类的继承体系中,父类有个方法用来计算:根据不同的子类来计算不同的value
    • 套用模板方法设计模式一样
  • Introduce Null Object(引入Null对象)
    • 针对null对象的设计模式
    • 可以将null时,业务逻辑的例外算法在NullObject中实现一份,这样在业务逻辑类中就不需要些一堆if null之类的判断以及转发了
  • Introduce Assertion(引入断言)
    • 在函数的入口编写Assert,用来确保被调用此函数时,相应的前置条件是否正确,使用
    • 如果断言失败,则会在日志文件中出现调用堆栈信息以及自定义信息
    • System.Diagnostics.Trace.Assert:无论是否Release,都会记录日志
    • System.Diagnostics.Trace.Debug:只在Debug模式下生成日志信息

简化函数调用

  • Rename Method(函数改名)
    • 修改函数命名为更有语义,提高可读性
    • 参数顺序、参数命名也是考虑之一
  • Add Parameter(添加参数)
    • 修改了一个函数,但是这个函数目前又需要用到以前所没有的信息
  • Remove Parameter(移除参数)
    • 以前的参数,现在不需要了
  • Separate Query from Modifier(将查询函数和修改函数分离)
    • 如果一个函数在返回值的过程中,也去修改了一些值,则会对客户端调用者产生某些困扰,需要将其拆分为2个函数:Query、Modify
  • Parameterize Method(令函数携带参数)
    • 在函数内部提取公用子函数,来实现代码的扁平化及公用化
  • Replace Parameter with Explicit Methods(以明确函数取代参数)
    • 当函数行为完全取决于参数value时,需要将这个函数拆分到多个方法,避免函数内部逻辑太杂
  • Reserve Whole Object(保持对象完整)
    • 当被调用函数的参数正好是某对象的其中几个属性时,则直接传入这个对象
    • 需要同时考虑被调用函数是否需要move到这个对象中
  • Replace Parameter with Methods(以函数取代参数)
    • 如果主函数中包含有多个子函数,并且这些子函数返回值只是首尾传入传出
    • 此时,考虑将除最后一个函数外,其他子函数不通过主函数来调用,而是通过最后一个字函数的内部进行调用
  • Introduce Parameter Object(引入参数对象)
    • 当某些参数总是成对、成堆出现时,考虑此模式
    • 如: DateTime from, DateTime end==> DateRange
    • int pageIndex, int pageSize==>PagingInfo
    • 以及PagingResult<T>{TotalCount, List<T>}
  • Remove Setting Method(移除设值函数)
    • 如果某个类的属性在构造后就不需要被改变,则把相应的set访问器关闭
  • Hide Method(隐藏函数)
    • 如果某函数没有被其他类引用到,就改成private的
  • Replace Constructor with Factory Method(以工厂函数取代构造函数)
    • 当类存在多个子类,并且希望通过类型码来生成新对象时,可以将构造函数改成工厂方法,这样便于客户端调用,无需知道到底是哪个子类
  • Encapsulate Downcast(封装向下转型)
    • 是说对于类型的强制转换,需要放在具体的函数中实现,不要放在客户端代码中
    • 现在.Net有了泛型,减少了很多这种麻烦
  • Replace Error Code with Exception(以异常取代错误码)
    • 在代码中如遇异常,则直接throw new XXXXException("xx"),而不是用return errorCode的方式
    • 如果是可控异常,则在catch(XXXException ex)处理掉
    • 如果是不可控异常,则无需处理
    • 不可控异常应有框架来处理,如AOP或者Global中的Error事件
  • Replace Exception with Test(以测试取代异常)
    • 对于滥用了catch异常的逻辑进行逻辑上的修改
    • 用单元测试+Assert+边界值测试来确保某些异常没有被触发

处理概括关系

  • Pull Up Field(字段上移)
    • 当多个子类中存在相似的字段时,需要分析下是否需要将这些相似的字段提取到父类中
  • Pull Up Method(函数上移)
    • 当多个子类中存在相似的函数时,需要分析下是否需要将这些相似的函数提取到父类中
    • 如果完全相同,那就直接提取到父类
    • 如果只是某个步骤不通,则通过模板方法把公用逻辑提升到父类中
  • Pull Up Constructor Body(构造函数本体上移)
    • 子类中的构造函数尽量利用父类的构造函数来赋值
  • Pull Down Method(函数下移)
    • 当父类中的某个函数只与某几个子类(非全部)有关时,则将这个函数下放到具体的子类中实现
  • Pull Down Field(字段下移)
    • 当父类中的某个字段只与某几个子类(非全部)有关时,则将这个字段下放到具体的子类中
  • Extract Subclass(提炼子类)
    • 当存在Type Code时,或者当类的某些instance存在不一样的行为时,需要提炼子类
    • 类的某些特性只被某些instance用到
  • Extract Superclass(提炼超类)
    • 如果多个类之间存在相似的特性,则可以新增一个超类将共性提取出来
  • Extract Interface(提炼接口)
    • 直接引用一个类,会将所有的方法暴露出来
    • 如果根据职责定义接口,再让类实现这些接口,调用时的封装、隐蔽性就会好很多
  • Collapse Hierarchy(折叠继承体系)
    • 当父类与子类之间的区别不大时,可以将它们合并,去掉层级关系
  • Form Template Method(塑造模板函数)
    • 其实就是模板设计模式的应用
  • Replace Inheritance with Delegation(以委托取代继承)
    • 当子类发现实际不需要使用集成来的数据、函数时,或者只用到了少数父类的数据、函数时,则可以去掉继承关系,在当前类中加上父类引用,通过委托方式来调用父类的数据、功能
  • Replace Delegation with Inheritance(以继承取代委托)
    • 当2个类之间使用了很多委托来进行调用,并且这些委托覆盖面为对方的大范围时,考虑将委托改成继承关系

大型重构

  • Tease Apart Inheritance(梳理并分解继承体系)
    • 桥接模式的分割
  • Convert Procedural Design to Objects(将过程化设计转化为对象设计)
    • OO对象的建立
    • 职责的分离
  • Separate Domain from Presentation(将领域和表述/显示分离)
    • MVC模式
    • MVVM模式
    • View与Domain的区分
  • Extract Hierarchy(提炼继承体系)
    • 开发封闭原则
      • 对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。
      • 对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。

 

 

 

posted @ 2014-04-10 03:13 McKay 阅读(...) 评论(...) 编辑 收藏