重构-改善既有代码的设计(三):代码的坏味道

1、重复代码

(1)设法将相同的程序结构合二为一,程序变得更好

(2)对于两个互为兄弟的子类内含有相同表达式,先提取共同的代码组成一个方法,然后放到超类中,使用模版设计模式

(3)两个毫不相关的类出现重复代码,考虑将重复代码提炼到一个独立类中,然后在类内使用这个新类

2、过长函数

(1)让小函数容易理解的关键在于一个容易理解的好名字

(2)每当感觉需要以注释说明的时候,就需要把要说明的东西写进一个独立函数,并以其用途命名

(3)确定提炼哪一段代码的方法:寻找注释,注释通常能指出代码用途和实现手法之间的语义距离

(4)条件语句和循环常常也是提炼的信号

3、过大的类

(1)先确定客户端如何使用它们,然后为每一种使用方式提炼出一个接口

4、过长的参数列表

(1)太长的参数列难以理解,太多参数会造成前后不一致,不易使用,而且一旦你需要更多的数据,就不得不修改它

(2)将来自同一对象的一堆数据收集起来,并以对象替换它们

(3)如果某些参数缺乏合理的对象归属,可为它们制造出一个“参数对象”

5、发散式变化

(1)一个类受多种变化的影响

(2)找出某特定原因而造成的所有变化,然后将其提炼到新的类中

6、霰弹式修改

(1)一种变化引发多个类相应的修改,应该把所有需要修改的代码放到同一个类

7、依恋情结

(1)将总是一起变化的东西放在一块儿

(2)数据和引用这些数据的行为总是一起变化的,若行为并非一起变化,则搬移那些行为

(3)策略模式和观察者模式使得修改函数行为更加轻松,因为它们将少量需被覆写的行为隔开

8、数据泥团

(1)现象:两个类中相同的字段,许多函数签名中相同的参数

(2)解决方法:将这些相同的字段提炼到一个独立对象中

9、基本类型偏执

(1)对象的一个极大价值在于:它们模糊了横旦与基本数据和体积较大的类之间的界限

10、switch惊悚现身

(1)面向对象程序的一个最为明显的特征:少用switch(或case)语句

(2)switch语句的问题在于重复,并且散布在不同地方,添加修改不太方便

(3)大多数情况下,考虑用多态来代替switch语句

11、平行继承体系

(1)让一个继承体系的实例引用另一个继承体系的实例

12、冗赘类

(1)如果一个类的所得不值其身价,就应该消除

13、夸夸其谈未来性

(1)不要以各式各样的钩子和特殊情况来处理一些非必要的事情,否则往往造成系统更难理解和维护

(2)如果函数或类的唯一用户是测试用例,应该将它们连同其测试用例一并删除

14、令人迷惑的暂时字段

(1)对于某种特定情况而设定的实例变量和相关函数,应该提炼到一个独立的类中

15、过度耦合的消息链

(1)一旦对象间的关系发生任何变化,过长的消息链就不得不做出相应的修改

16、中间人

(1)尽量避免过度运用委托

17、狎昵关系

(1)过分狎昵的类必须拆散

(2)继承往往造成过度亲密,因为子类对超类的了解总是超过后者的主观愿望

18、异曲同工的类

(1)若两个函数做同一件事,却有着不同的签名,请根据它们的用途重新命名

19、不完美的库类

(1)复用常常被视为对象的终极目的

20、纯稚的数据类

(1)数据类指拥有一些字段和读写这些字段的方法

21、被拒绝的遗赠

(1)子类应该继承超类的数据和函数

22、过多的注释

(1)代码能够说明的时候,注释就变得多余

(2)当你感觉需要撰写注释时,请先尝试重构,试着让所有注释都变得多余

 

尾注

  • 上述的总结与思考是基于对《重构—改善既有代码的设计》这本书的精读与演绎
  • 更多及时干货,请关注微信公众号:JAVA万维猿圈

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值