代码的坏味道

代码的坏味道

Duplicated Code(重复代码)

同一个类的两个函数含有相同的表达式或互为兄弟的子类内含有相同表达式

Long Method(过长函数)

拥有短函数的对象会活的比较好、比较长
遵循的原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名

Large Class(过大的类)

过大的类往往影响阅读，且其中必定含有可分解提炼的方法，

Long Parameter List(过长参数列)

将来自同一对象的一堆数据收集起来

Divergent Change(发散式变化)

针对某一外界变化的所有相应修改，都只应该发生在单一类中，如果某一变化总是影响到多个函数的修改，则应该把这多个函数提炼到另一个类中

Shotgun Surgery(霰弹式修改)

如果某一变化必须在许多不同的类里做出许多小修改，则应该把所有需要修改的代码放进同一个类里

Feature Envy(依恋情结)

函数对某个类的兴趣高过对自己所处类的兴趣，则应该把它移动到这个类里

Data Clumps(数据泥团)

把很多常常一起出现的数据提炼到一个新数据类里

Primitive Obsession(基本类型偏执)

判断所用数据是基本类型好还是对象好，灵活运用

Switch Statements(switch惊悚现身)

switch往往伴随着重复，当然也不是不能用switch，比如有几种电影类型，每种电影价格不同且每种电影积分也不同时，就可能会出现使用两次甚至更多次switch(电影类型)的重复代码

Parallel Inheritance Hierarchies(平行继承体系)

每当为某个类增加一个子类，必须也为另一个类相应增加一个子类

Lazy Class(冗赘类)

去除没用的类

Speculative Generality(夸夸其谈未来性)

去除没用的抽象类

Temporary Field(令人迷惑的暂时字段)

尽量少用局部变量

Message Chains(过度耦合的消息链)

避免函数调用链过长

Middle Man(中间人)

某个类接口有一半的函数都委托给其他类，则应让它直接和真正负责的对象打交道

Inappropriate Intimacy(狎昵关系)

两个类过于亲密，则应把两者的共同点提炼到一个新类里

Alternative Classes with Different Interfaces(异曲同工的类)

两个函数做同一件事，应该提炼相同部分

Incomplete Library Class(不完美的库类)

根据修改库类的函数多少选择继承库类还是包装库类

Data Class(纯稚的数据类)

数据类应该充分的封装，做到数据的安全

Refused Bequest(被拒绝的遗赠)

子类不想继承一些父类的某些函数和数据，应该为子类新建一个兄弟类，把所有不需要继承的函数和数据推给这个兄弟类

Comments(过多的注释)

注释越少越好，通过重构手法把需要注释的类或函数提炼