重构(三) -- 代码的坏味道

味道

重构中的味道是用来形容重构时机的一些场景

常见坏味道

  • 重复代码(duplicated code)
    1:同一个类的两个函数含有相同的表达式,需要将重复的代码提炼出来
    2:互为兄弟的子类中含有相同表达式,将相同代码提炼到超类中,其中可能使用模板设计模式
    3:毫无相关的两个类含有相同的表达式,将相同代码提炼到独立类中

  • 过长函数
    1:常见场景中,可以找到函数中适合集中在一起的部分,提炼出一个新函数,并努力通过方法名称来表明函数用途
    2:如果函数内有大量参数和临时变量导致方法可读性不高,可以使用查询代替传参的方法消除传参
    3:如果代码前方有一行注释,可以考虑是否需要提起成单独的函数,条件表达式和循环也可以考虑是否提炼

  • 过大的类
    1:过大的类里面容易有多个实例变量和太多重复代码,可以考虑提炼出子方法或者子类

  • 过长参数列
    1:通过对象解决传参参数过多问题

  • 发散式变化
    1:发散式变化就是形容一个类或方法经常因为不同的原因在不同的方向上发生变化,可以考虑进行拆分,譬如新加入一个数据库,就应该修改一个类就好

  • 霰弹式修改
    1:遇到某种变化,如果需要在许多不同的类中做许多小修改,这样应该将需要修改的代码放入同一个类中进行维护。

  • 依恋情节
    1:面向对象技术中将数据和对数据的操作行为封装在一起,此时很可能某个函数为了计算某个值,从
    另一个对象调用太多的取值函数,此时应该将函数移动另一个对象中。
    2:如果一个函数调用几个类的功能,原则是判断哪个类拥有最多被此函数使用的数据,就将函数放进去。

  • 数据泥团
    1:数据泥团主要表示很多地方有三四项数相同的字段数据,主要找出这些数据形成一个类

  • 基本类型偏执
    1:中心思想在于两三个基本数据类型在必要的情况下也应该抽象成类

  • switch statements
    1:少用switch语句,因为switch语句很容易重复出现,此时可以考虑用策略等模式处理

  • 平行继承系
    1:如果每当为某个类增加一个子类,必须也为另一个类相应增加一个子类,那么可以让一个继承体系的实例引用另一个继承体系的实例

  • 冗赘类
    1:中心思想就是删除一些没必要的类,对于某些子类可以考虑与其他类合并的方式去除

  • 夸夸其谈未来性
    1:中心思想就是以未来可能使用到来写增加一些类,但是如果是非必要性的需要考虑是否需要,譬如函数或类只在测试用例中使用,这种就考虑和测试用例一起删除掉

  • 令人迷惑的暂时字段
    1:某类某个实例变量仅为某种特定情况而设,这种情况可以使用额外的类

  • 过度耦合的消息链
    1:有一种情况是A请求了B获取B实例b,然后通过b调用C的实例d,这种情况可以实例d直接委托到C,不需要在通过b

  • 中间人
    1:因为有时候可能会过度运用委托,此时可以考虑去掉一些委托改成直接调用

  • 狎昵关系
    1:狎昵关系表示类之间过于亲密,需要花费太多时间去探究彼此private成分,这明显也不符合单一原则,常常可以将共同点提炼出来

  • 异曲同工的类
    1:如果两个函数做同一件事,却有着不同的名称,此时可以重新命名并修改调用

  • 不完美的类库
    1:有时候类库无法提供想要的方法且无法直接修改类库,此时可以通过外加函数引入本地拓展的方式解决

  • 纯稚的数据类
    1:纯稚的数据类是指拥有一些字段,以及用于访问这些字段的函数,除此之外一无长物。对于此类中的一些字段数据需要通过一些方法封装起来

  • 被拒绝的遗赠
    1:如果子类不想或者不需要继承超类的函数或者数据,此时可能需要考虑增加超类等方式限制方法的使用

  • 过多的注释
    1:过多的注释可能代表着代码很糟糕,所需需要考虑通过优化代码的方式直接表明方法用途

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容