目录
- 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个类做的事。建立一个新类，将相关的字段和函数从旧类搬移到新类。动机：
- 一个类应该是一个清楚地抽象，处理一些明确的责任。不这样的类往往含有大量函数和数据，而且太大不易理解此时你需要考虑哪些部分可以分离出去，并将它们分离到一个单独的类中。如果某些数据和某些函数总是一起出现，某些数据经常同时变化甚至彼此依赖，这就表示你应该将它们分离出去。一个有用的测试就是问自己，如果搬移了某些字段和函数，会发生什么事？其他字段和函数是否因此变得无意义。
- 另一个往往在开发后期出现的信号时类的子类化方式。如果你发现子类化只影响类的部分特性，或如果你发现某些特性需要以一种方式来子类化，某些特性则需要以另一种方式子类化，这就意味着你需要分解原来的类
- 提炼子类:类中的某些特性只被某些实例用到；新建一个子类，将上面所说的那一部分特性移到子类中
过长参数列
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成分
- 解决方案:
- 使用 move method和move field帮它们划清界线
- 使用extract class把两者共同点提炼到一个安全地点
不完整的类库
- 封装好的类库中功能不能满足实际需求，库中没有某些需求能够使用的方法函数等，封装好的库不能更改
- 使用 Introduce Local Extension(引入本地扩展)
RefusedBequest（被拒绝的遗赠）
过多的注释
- 当你感觉需要写注释的时候，请先尝试重构，试着让所有的注释都变的多余。
参考文章
