1，什么是重构？
- 是在不改变系统行为的前提下，对内部代码的重新组织，提高可理解性和降低修改成本。
2，为什么要重构？
- 一个小修改牵涉到了多个地方，且这些点处于未知状态
- 不易读懂代码（包括读懂自己1个月前的代码）
- 新手修改代码上手慢，需要很久才能进行有信息的代码修改
- 需求变化时，代码层面响应慢
3，什么时候需要重构？
- 随时随地的重构，也就是从一开始就进行小范围的重构，就不至于时间久后没法平滑的重构了
- 上面这句实际上是个方法论级别的，真实中，还是没办法判断什么时候要进行重构，于是换成：当代码中出现了坏味道时需要重构
- 什么是坏味道：
- 存在重复代码时
- 函数体太长
- 函数参数太长
- 无法直观的看出代码逻辑
- 类太大
- 对一个常量存在了多个副本
- 很多很多的if/else/switch语句
- 类名、函数名、方法名不友好
4，重构与性能
- 重构为先，调优其次
- 重构能组织良好的结构，良好的结构能让调优工作更轻松
@下边是一些重构方法：
重新组织函数
- 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(提炼继承体系)
- 开发封闭原则
- 对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
- 对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。
- 开发封闭原则
