找出那些代码里的坏味道吧——《重构》笔记

一、重构原则

1.重构的定义

• 重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

• 重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

• 关于重构需要强调的两点：

  • 重构的目的是使软件更容易被理解和修改。
  • 重构不会改变软件可观察的行为——重构之后软件功能一如以往。

2.重构的目标

• 进行重构之后，我们希望我们的程序能达到以下几点目标：
  • 容易阅读
  • 所有逻辑都只在唯一地点指定
  • 新的改动不会危及现有行为
  • 尽可能简单表达条件逻辑

3.何时不该重构

• 现有代码根本不能正常运行时，应该重写，而不应重构。
• 如果项目已近最后期限，你也应该避免重构。

二、代码的坏味道

• Duplicate Code（重复代码）
  • 如果你在一个以上的地点看到相同的程序结构，那么可以肯定，设法将它们合二为一，程序会变得更好。
• Long Method（过长函数）
  • 拥有短函数的对象会活的比较好，比较长。
  • 我们遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。
  • 条件表达式和循环常常也是提炼的信号。
• Large Class（过大的类）
  • 如果想利用单个类做太多事情，其内往往就会出现太多实例变量。
  • 和“太多实例变量”一样，类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。最简单的解决方案是把多余的东西消弭于类内部。
  • 这里有个技巧：先确定客户端如何使用它们（指“太多的实例变量”），然后运用Extract Interface为每一种使用方式提炼出一个接口。这或许可以帮助你看清楚如何分解这个类。
• Long Parameter List（过长参数列）
  • 如果你手上没有所需的东西，总可以叫另一个对象给你。因此，有了对象，你就不必把函数需要的所有东西都以参数传递给它了，只需传给它足够的、让函数能从中获得自己需要的东西就行了。
• Divergent Change（发散式变化）
  • 针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应此变化。
• Shotgun Surgery（霰弹式修改）
  • Divergent Change是指“一个类受多种变化的影响”，Shotgun Surgery则是指“一种变化引发多个类相应的修改”。这两种情况下你都会希望整理代码，使“外界变化”与“需要修改的类”趋于一一对应。
• Feature Envy（依恋情结）
  • 函数对某个类的兴趣高过对自己所处类的兴趣。
  • 判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据摆在一起。
  • 最根本的原则是：将总是一起变化的东西放在一块儿。数据和引用这些数据的行为总是一起变化的，但也有例外。如果例外出现，我们就搬移那些行为，保持变化值在一地发生。
• Data Clumps（数据泥团）
  • 你常常可以再很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真应该拥有属于它们自己的对象。
• Primitive Obsession（基本类型偏执）
  • 对象的一个极大的价值在于：它们模糊（甚至打破）了横亘于基本类型和体积较大的类之间的界限。你可以轻松编写一些与语言内置（基本）类型无异的小型类。
• Switch Statements（switch惊悚现身）
  • 面向对象程序的一个最明显特征就是：少用switch（或case）语句。
  • 大多数时候，一看到switch语句，你就应该考虑以多态来替换它。
  • 如果你只是在单一函数中有些选择事例，且并不想改动它们，那么多态就有点杀鸡用牛刀了。
• Parallel Inheritance Hierarchies（平行继承体系）
  • 每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。
  • 消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
• Lazy Class（冗赘类）
  • 你所创建的每一个类，都得有人去理解它，维护它，这些工作都是要花钱的，如果一个类的所得不值其身价，它就应该消失。
• Speculative Generality（夸夸其谈未来性）
  • 如果所有装置都会被用到，那就值得那么做；如果用不到，就不值得。用不上的装置只会挡你的路，所以，把它搬开吧。
• Temporary Field（令人迷惑的暂时字段）
  • 有时你会看到这的对象：其内某个实例变量仅为某个特定情况而设。
  • 请使用Extract Class给这个可怜的孤儿创造一个家，然后把所有和这个变量相关的代码都放进这个新家。
• Message Chains（过度耦合的消息链）
  • 如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象……这就是消息链。
• Middle Man（中间人）
  • 人们可能过度运用委托。你也许会看到某个类接口有一半的函数都委托给其他类，这样就是过度运用。
• Inappropriate Intimacy（狎昵关系）
  • 有时你会看到两个类过于亲密，花费太多时间去探究彼此的private成分。
  • 就像古代恋人一样，过分狎昵的类必须拆散。
  • 继承往往造成过度亲密，因为子类对超类的了解总是超过后者的主观愿望。
• Alternative Classes With Different Interfaces（异曲同工的类）
  • 如果两个函数做同一件事，却有着不同的签名。
• Incomplete Library Class（不完美的类库）
  • 如果你只想修改类库的一两个函数，可以运用Introduce Foreign Method；如果想要添加一大堆额外行为，就得运用Introduce Local Extension。
• Data Class（纯稚的数据类）
  • 所谓Data Class是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。
  • Data Class就行小孩子，作为一个起点很好，但若要让它们像成熟的对象那样参与整个系统的工作，它们就必须承担一定责任。
• Refused Bequest（被拒绝的遗赠）
  • 如果子类复用了超类的行为（实现），却又不愿意支持超类的接口，Refused Bequest的坏味道就会变得浓烈。
• Comments（过多的注释）
  • 常常会有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。
  • 如果你不知道该做什么，这才是注释的良好运用时机。

三、两句重要的话

• 重构的基本技巧——小步前进，频繁测试。
• 模式是你希望到达的目标，重构则是到达之路。