目录

• DuplicatedCode（重复代码）
• LongMethod（过长函数）
• LargeClass（过大的类）
• LongParameterList（过长参数列）
• DivergentChange（发散式变化）
• ShotgunSurgery（霰弹式修改）
• FeatureEnvy（依恋情结）
• DataClumps（数据泥团）
• PrimitiveObsession（基本类型偏执）
• SwitchStatements（switch惊悚现身）
• SpeculativeGenerality（夸夸其谈未来性）
• MessageChains（过度耦合的消息链）
• MiddleMan（中间人）
• InappropriateIntimacy（狎昵关系）
• IncompleteLibraryClass（不完美的库类）
• RefusedBequest（被拒绝的遗赠）
• Comments（过多的注释）

---

代码的坏味道

重复代码

• 同一个类的两个韩硕含有相同的表达式时采用：提炼函数
• 两个互为兄弟的子类内含有相同的表达式时：首先提炼函数 然后使用 函数上移将它推入超类。
• 两个互为兄弟的子类代码只是类似，并非完全相同，那么可以运用Extract Method（提炼函数） 然后运用 Form Template Method（塑造模板函数） （PS：模板函数即子类重写的函数）
• 两个毫不相干的类出现重复代码，应使用 Extract Class（提炼类） 把重复代码提炼成公共函数。

过长函数

• 每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中。并以其用途（非其实现手法）命名
• 分解函数常用方法重新组织函数
• 分解条件表达式，就是把if里面的条件抽出来，提高可读性

过大的类

• 通过运用提炼类: 某个类做了应该由2个类做的事。建立一个新类，将相关的字段和函数从旧类搬移到新类。动机：

1. 一个类应该是一个清楚地抽象，处理一些明确的责任。不这样的类往往含有大量函数和数据，而且太大不易理解此时你需要考虑哪些部分可以分离出去，并将它们分离到一个单独的类中。如果某些数据和某些函数总是一起出现，某些数据经常同时变化甚至彼此依赖，这就表示你应该将它们分离出去。一个有用的测试就是问自己，如果搬移了某些字段和函数，会发生什么事？其他字段和函数是否因此变得无意义。
2. 另一个往往在开发后期出现的信号时类的子类化方式。如果你发现子类化只影响类的部分特性，或如果你发现某些特性需要以一种方式来子类化，某些特性则需要以另一种方式子类化，这就意味着你需要分解原来的类

• 提炼子类:类中的某些特性只被某些实例用到；新建一个子类，将上面所说的那一部分特性移到子类中

过长参数列

• 以函数取代参数

public int gamma(int inputVal,int quantity,int yearToDate){
        int importantValue1 = (inputVal * quantity)+100;
        int importantValue2 = (inputVal * yearToDate)+100;
        if((yearToDate-importantValue1)>100){
            importantValue2-=20;
        }
        int importantValue3 = importantValue2 * 7;
        return importantValue3 - 2*importantValue1;
    }
 
    public int gammaRepair(int inputVal,int quantity,int yearToDate){
        return new RepMethodObject(inputVal,quantity,yearToDate).gamma();

• 保持完整对象: 你从某个对象中取出若干值，将它们作为某一次函数调用时的参数；改为传递整个对象
• 引入参数对象，将参数对象化。

发散式变化

• 指一个类受多种变化的影响, 通过运用提炼类使其每个对象只受一个变化影响

散弹式修改

• 指一种变化引发多个类相应的修改
• 通过使用搬移函数: 如果一个类有太多的行为，或者如果一个类与另一个类有太多合作而形成高度耦合，这时候就应该搬移函数。通过这种手段，可以使系统中的类更简单，这些类最终也将更干净利落地实现系统交付的任务。
• 移动字段: 如果发现，一个字段在其所驻类之外的另一个类有更多函数使用了它，就应该考虑搬移这个字段。
• 将类内联化: “将类内联化”正好与”提炼函数“相反。如果一个类并没有做太多的事，不再承担足够的责任，不再有单独存在的理由。这通常是由于在之前的重构动作中移走了对这个类的责任。挑选这一”萎缩类“的最频繁的用户（另一个类），以”将类内联化“手法将该”萎缩类“塞进另一个类。

依恋情结

• 判断哪个类拥有最多被此函数使用的数据，然后就把这个函数通过移动函数和那些数据摆在一起。如果函数中只有一部分，应该运用提炼函数把这一部分提炼出去.

数据泥团

• 减少字段和参数的个数，提炼新对象

基本类型偏执

• 使数值尽量用类代替，就像java中的基本类型那样
• 坏处: 单独存在的数值不易于理解，也不符合面向对象的思想

switch 惊悚现身

• 使用多态来替换switch(但是实际生产环境的代码一般switch的流程相对简单易懂，很少去用多态代替)

夸夸其谈的未来性

• 经常在理解需求的时候主观的认为需求变动非常大，那么在设计过程中就会出现过度的设计
• 求设计模式的使用，经常对程序的不必要的地方进行设计模式的使用，导致代码不易理解
• 程序的设计过程中封装变化混乱，没有将封装变化进行到底
• 过度考虑了程序的未来性，但这些未来性并不明确

过度耦合的消息连

• 如果你看到用户向一个对象请求另一个对象, 然后再向后者请求另一个对象, 然后再请求另一个对象.......... 这就是消息链条。
• 实际代码中你看到的可能是一长串getThis或一长串临时变量，意味着客户代码将与查询工程中的导航结构紧密耦合. 一旦对象间的关系发生了任何变化, 客户端就不得不做出相应修改.
• Hide Delegate(隐藏委托关系)解决

class Person {
    Department _department;

    public Department getDepartment(){
        return _department;
    }

    public void setDepartment (Department arg){
        _department = arg;
    }
    
}

class Department{
    private String _chargeCode;
    private Person _manager;

    public Department (Person manager){
        _manager = manager;
    }

    public Person getManager{
        return _manager;
    }

}
//如果客户希望知道某人的经理是谁, 他必须先获得Department对象:
manager = john.getDepartment().getManager();
//修改下加个函数
public Person getManager(){
    return _department.getManager();
}
//这时候就对客户端隐藏了Department和Person 关系
manager = john.getManager();

中间人

• 类中的函数存在过度委托给其他对象的情况。
• 多余的代码，中间人作用小。
• 使用Remove Middle Man(移除中间人)来减少无用的委托对象

InappropriateIntimacy（狎昵关系）

• 两个类过于亲密，花费太多时间去探究彼此的private成分
• 解决方案:

1. 使用 move method和move field帮它们划清界线
2. 使用extract class把两者共同点提炼到一个安全地点

不完整的类库

• 封装好的类库中功能不能满足实际需求，库中没有某些需求能够使用的方法函数等，封装好的库不能更改
• 使用 Introduce Local Extension(引入本地扩展)

RefusedBequest（被拒绝的遗赠）

• 重构分析21: 被拒绝的遗赠（Refused Bequest）文中的例子举的很多，其中继承要遵循LSP(里氏替换原则):子类必须能够替换掉他们的父类,即父类出现的地方就可以使用子类来代替，而且不会出现任何错误或者异常。

过多的注释

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

---

参考文章

• 重构分析21: 被拒绝的遗赠（Refused Bequest）
• 过度耦合的消息链
• 重构手法12：Extract Class （提炼类）
• 重构-以函数对象取代函数
• 读《重构-改善既有代码的设计》第三章：代码的坏味道
• 重构：改善既有代码的设计目录