重构-代码的坏味道

---

1、Duplicated Code (重复代码)
 相同的代码在多处重复出现,在同一个类中，使用Extract Method提取重复的代码。或者，在不同的子类中，可以先Extract Method, 然后Pull up Method, 将其推入超类中，有可能代码只是相似而不是完全相同，可以使用Form Template Method，也又可能不同算法做着相同的事，此时，可以用Substitute Algorithm将其它函数替换掉。或者，在两个毫不相干的类中，此时，可以尝试将方法放置在其中一个类或者第三个类中，在其它类中保留方法所在类的引用。
2、Long Method（过长函数）
 函数过长，可能是一个函数做了太多的事情。将函数功能拆分，最好的情况是能通过命名便知晓函数的功能。
3、Large Class（过大的类）
 如果利用单个类做太多事情，其内往往会出现太多实例变量。或者会导致类中有太多代码，此时Extract Class便很重要
4、Long Parameter List（过长参数列）
 太多参数会造成前后不一致、不易使用，而且一旦你需要更多数据，就不得不修改。如果将对象传递给函数，大多数修改都将没有必要，因为你很可能只需（在函数内）增加一两条请求，就能得到更多数据。
5、Divergent Change（发散式变化）
 如果某个类经常因为某种原因在不同的方向上变化，Divergent Change就出现了。此时也许将这个对象分成两个更好，这样每个对象就只因一种变化而需要修改。最好的情况是，针对某一外界变化的所有响应修改，都只发生在单一类中。
6、Shotgun Surgery（散弹式修改）
 如果遇到某种变化，你需要在许多不同的类中做出许多小修改，这就是Shotgun Surgery。这种情况下应该使用Move Field和Move Method将所有需要修改的变化放到同一个类中。
 Divergent Change是指“一个类受多种变化的影响”，Shotgun Surgery是指“一种变化引起多个类的修改”。
7、Feature Envy（依恋情结）
 对象技术的全部要点在于，这是一种“将数据和对数据的操作行为包在一起”的技术。有一种经典气味是：函数对某个类的兴趣高于自己所处类的兴趣。这种情况的焦点通常是数据。无数次经验里，可以看到某个函数为了计算某个值，从另一个对象那几乎调用了半打函数。此时，应该使用Move Method将它移到该去的地方。
 当然，并非所有情况都这么简单，一个函数往往会用到几个类的功能。此时，放置的原则是：判断哪个类拥有最多被此函数使用的数据， 然后把这个函数和那些数据摆在一起。
 有几个复杂精巧的设计模式破坏了这一规则。Strategy和Visitor。
8、Data Clump（数据泥团）
 你常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据应该拥有属于它们自己的对象。首先找出这些数据以字段形式出现的地方，运用Extract Class将它们提炼到一个对象中。然后将注意力移到函数签名中，运用Introduce Parameter Object和Preserve Whole Object为它减肥。
 一个好的评判方法是：删掉众多数据中的一项。这么做，其他数据有没有因而失去意义？如果有，你应该为它们产生一个新对象。
9、Primitive Obsession（基本类型偏执）
 对象的一个极大的价值在于：它们模糊（甚至打破了）横亘于基本数据和体积较大的类之间的界限。你可以轻松编写出一些与语言内置（基本）类型无异的小型类。可以尝试将一些类型码或者总被放在一起的字段提取到一个类中。
10、Switch Statements（switch声明）
 减少switch语句，避免过多的重复。可以使用Replace Type Code with Subclass或Replace Type Code with State/Strategy，以多态替换它。如果只是单一函数中有些选择事例，那么多态有点富余了。这种情况下Replace Parameter with Explicit Methods是个不错的选择。
11、Parallel Inheritance Hierarchies（平行继承体系）
 
12、Lazy Class（冗赘类）
13、Speculative Generality（夸夸其谈未来性）
 移除不必要的委托，类，函数。
14、Temporary Field（令人迷惑的暂时字段）
 对象内某个实例变量仅为某种额定情况而设，这样的代码有时难以理解。通过Extract Class将变量和相关代码提炼到一个独立的类中。
15、Message Chains（过度耦合的消息链）
 
16、Middle Man（中间人）
 你也许会看到某个类接口有一般的函数都委托给其他类。这是应该使用Remove Middle Man，直接和真正负责的对象打交道。
16、Inappropriate Intimacy（狎昵关系）
 两个类之间不应该过度关注对方的private成分
17、Alternative Classes with Different Interfaces（异曲同工的类）