第三章 代码的坏味道

重复代码（Duplicated Code）

• 同一个类中的两个函数
• 互为兄弟的子类内
• 两个毫不相关的类

过长函数（Long Method）

• 程序越长越难让人理解
• 应该遵循：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名

过大的类（Large Class）

• 使用Extract Class 和 Extract Subclass方法将几个相关的变量一起提炼至新类

过长参数列表（Long Parameter List）

• 如果你手上没有所需的东西，总可以叫另一个对象给你
• Replace Parameter with Method

发散式变化（Divergent Change）

• 我们希望，软件一旦需要修改，能够跳到系统的某一点，只在该处做修改
• 针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应此变化，为此，你应该找出某特定原因而造成的所有变化，然后运用Extract Class将它们提炼到另一个类中。

散弹式修改（Shotgun Surgery）

• 表现：每遇到某种变化，必须在许多不同的类内做出许多小修改
• 影响：很难找到，容易漏掉重要修改
• 解决方法：把所有修改的代码放到同一个类

依恋情节（Feature Envy）

• 表现：函数对某个类的兴趣高过对自己所处类的兴趣。从另一个对象那儿调用大量取值函数，完成某种计算
• 解决方法：Move Method

数据泥团（Data Clumps）

• 表现：很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数
• 评判标准：删掉众多数据中的一个，其他数据变得不再有意义
• 解决方法：将绑在一起出现的数据提取到一个类中

基本类型偏执（Primitive Obsession）

• 两种数据类型：结构类型允许你将数据组织成有意义的形式；基本类型这是构成结构类型的积木块。
• 要善于运用类对象，简单类、小对象

Switch惊悚现身（Switch Statements）

• 面向对象程序的一个最明显特征：少用switch（或case）语句。从本质上说，switch语句的问题在于重复。你常会发现，同样的switch语句散布于不同地点。很难维护。
• 解决方法：多态

平行继承体系（Parallel Inheritance Hierarchies）

• 表现：每当你为一个类添加一个子类，必须也为另一个类相应增加一个子类
• 解决方法：让一个继承体系的实例引用另一个集成体系的实例

冗赘类（Lazy Class）

• 如果一个类的所得不值其身价，他就应该消失

夸夸其谈未来性（Speculative Generality）

• 没太大作用的抽象类，不必要的委托，函数的某些参数未被用上，函数名称带有多余的抽象意味

令人迷惑的暂时字段（Temporary Field）

过度耦合的消息链（Message Chains）

对象a 请求对象b, 对象b请求对象c …

中间人（Middle Man）

过度使用委托。

狎昵关系（Inappropriate Intimacy）

现象：两个类花费太多时间去探究彼此的private成分。
对策：拆散，划清界限。

异曲同工的类（Alternative Classes with Different Interfaces）

现象： 两个函数做同一件事，却有着不同的签名

不完美的库类（Incomplete Library Class）

• 现象：使用的库类构造不够好，往往不可能让我们修改其中的类使它完成我们希望完成的工作
• 对策：Introduce Foreign Method, Introduce Local Extension

纯稚的数据类（Data Class）

• 数据类：拥有一些字段，以及访问（读写）这些字段的函数。数据容器。

被拒绝的遗赠（Refused Bequest）

• 子类集成了超类的函数和数据，但只是用其中一部分
• 给子类建兄弟类，使用Push Down Method和Push Down Field把所有用不到的函数推给兄弟类。

过多的注释（Comments）

• 当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变的多余