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

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万维猿圈