重构 第三章 代码的坏味道

Duplicated Code（重复的代码）

1.同一个类的两个函数含有相同的表达式，相同的表达式抽成一个方法，然后调用这个方法。

2.同一个父类有不同的子类，子类中有公共的方法，把公共的方法放到父类中去执行。

3.如果两个没有关系的类出现了重复的代码，把重复的代码抽离出来，封装成一个新的方法，然后调用这个新方法即可。

Long Method（过长函数）

1.函数过长，需要变小，对过长函数进行分解。

2.当过长函数里面出现循环语句和选择语句时，一般都可以把里面的功能进行提炼，抽成一个方法。

3.对大量参数和临时变量的处理还没很理解。

Large Class（过大类）

单个类所实现的功能太多（我是怎么理解的），导致这个类中出现大量的变量，我们可以根据功能或者一定条件把相关变量提炼到一个新类中。

Long Parameter List（过长参数列）

方法中参数过多，难以理解，容易出错。可以将参数封装成对象，传递对象。

Divergent Change（发散式变化）

（自己理解）当某个需求修改的时候，很多地方的方法都要修改。我们可以在设计代码的时候就提供不同需求的选择。例如：一个人饲养一只猫，给猫喂猫粮，当有一天他又有了一条狗，把猫送人了，给狗喂狗粮。那么这种情况我们在饲养动物的方法里就不应该写固定，而是传递一个动物对象，根据不同的动物对象，执行不同的方法，即使后面的需求修改了，我这边的方法依旧不需要修改。

Shotgun Surgery（散弹式修改）

这个问题在我们代码里面的体现就是常常用常量来表示一些字段，比如网络地址，数据库表名，当代码中用到了这些字段的时候，直接饮用常量，修改时直接修改常量即可，不用去找哪些地方用了这个字段，然后逐一修改。

Feature Envy（依恋情结）

这类问题的体现形式就是一个类调用了过多其他类的方法（我的开发中暂时还没遇到这类问题），解决方案就是判断哪个类拥有最多被此方法调用的数据，然后将此方法移动到对应的类。最根本的原则就是：将总是一起变化的东西放在一起。

Data Clumps（数据泥团）

（理解不是很清晰）暂时理解就是总是绑在一起的数据应该拥有属于他们自己的对象，比如一个产品的价格和名字id，应该有一个产品对象，在这个产品对象中有价格和id两个属性。

Primitive Obsession（基本型别偏执）

   （开发中，我对这个问题不敏感，只能借鉴其他人的理解）例如：保险中的起止与结束日期，应该建立一个新的类，而不是【string startDate，string endData】两个字符串类型或者日期类型来表示。①将一些数据值替换成对象。②用类取代类型码。

Switch Statements（switch惊悚现身）

问题的体现就是出现大量的的switch/case语句，从本质上说，switch语句的问题在于重复，可以用面向对象中多态的思想进行修改。

Parallel Inheritance Hierarchies（平行继承体系）

  出现这类问题比较好发现，为某个类增加子类，就必须为另外一个类也增加子类。解决此问题的办法就是让一个继承体系继承另外一个继承体系，就可以完美解决。

Lazy Class（冗赘类）

一个类做的事情和实现的功能很少，不值其身价，我们就应该想办法让它消失。

Speculative Generality（夸夸其谈未来性）

特殊（非必要）情况的下会出现，目前还没有用到（通俗来说就是费代码或者说执行率很低），我们应该想办法让他消失。

Temporary Field（令人迷惑的暂时值域）

       不清楚实例变量的含义（此方法没有用到，但是其他方法用到了），我们应该为这类变量安置一个新家。

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

      当一个对象请求另一个对象依次请求下去的时候，观察消息链最终对象用处，可以将这个过程封装成一个方法，将此方法推入到消息链中。

Middle Man（中间转手人）

    调用其他类方法的时候，其他类过多的调用了另外类的方法（过度委托）。

Inappropriate Intimacy（狎昵关系）

（暂时还没遇到）两个类的方法和成员互相使用，可以将两个类提炼成一个类或者改用继承体系。

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

两个方法实现相同的一个功能，仅仅是签名不同（让这个方法提到超类中）。

Incomplete Library Class（不完美的程序库类）

   系统api的功能满足不了我们的需求（暂不涉及）。

Data Class（纯稚的数据类）

结合我的开发，我觉得这类问题处理方式就是纯粹的数据常量（URL）需要封装，不支持让所有能用到此常量的对象进行修改。

Refused Bequest（被拒绝的遗赠）

  这类问题我也没遇到过，体现形式就是不需要继承但是继承了或者说不想继承他所有的方法或者属性，需要继承但是不想实现父类实现的接口.解决思路就是为其子类建立一个兄弟类，把公共部分数据放在父类中，其他数据选择放入子类。

Comments（过多的注释）

这个问题可以说是上面问题的一个汇总，当你写完一段代码，总需要很多注释才能让别人或者自己明白这段代码的功能和参数含义，这时候你就应该查找一下你的代码是否出现了上面提到的问题，然后进行重构。