返回总目录
十四、Temporary Field(令人迷惑的暂时字段)
1、某个实例变量仅为某种特定的情况而设
2、某些实例字段仅为某个函数的复杂算法少传参数而设
将这些变量和相关函数提炼到一个独立的类中。
十五、Message Chains(过度耦合的消息链)
如果你看到用户向一个对象请求另一个对象,然后再向后者请求另一个对象,然后在请求另一个对象……这就是消息链。
实际代码就是一长串的getThis()或者一长串临时变量。
使用隐藏“委托关系”(这个后面会讲)来进行重构。当然了,可以在消息链的任何位置运用。
十六、Middle Man(中间人)
过度运用委托。
1、某个类接口有一半的函数都委托给其他类,这时应“移除中间人”:让客户直接调用委托类。
2、如果只有少数几个函数,那就直接调用
3、如果中间人还有其他行为,以继承取代委托,让委托类继承受托类。
十七、Inappropriate Intimacy(狎昵关系)
两个类过于亲密必须拆散。
1、可以提炼一个类,将两者的共同点提炼到这个类中。
2、可以去掉类之间不必要的关联。
3、将继承改为委托,把子类从继承体系移出
十八、Alternative Classes with Different Interfaces(异曲同工的类)
两个函数做同一件事,但是签名不同。将两个函数合并,并根据用途重新命名。
十九、Incomplete Library Class(不完美的类库)
类库函数构造的不够好,又不能修改它们
1、如果只想修改类的一两个函数,可以引入外加函数。
2、如果想要添加一大堆额外行为,建立一个新类包含这些额外行为,让其成为子类。
二十、Data Class(纯稚的数据类)
所谓Data Class:类只有一些字段,以及访问这些字段的函数。
1、如果拥有public字段,则将其封装起来
2、如果拥有集合类字段,则将其封装起来
3、对于不能修改的字段,去除set方法
二十一、Refused Bequest(被拒绝的遗赠)
派生类仅使用了基类很少一部分成员函数
如果子类复用了父类的行为(实现),却又不愿意支持基类的接口,那就使用委托替代继承。
二十二、Comments(过多的注释)
常常有这种情况:一段代码有着长长的注释,而这些注释之所以存在是因为代码很shit。
这时候我们可以先找到各种“坏味道”,然后重构它。
当你感觉需要撰写注释时,请先尝试重构,试着让所有的注释都变得多余。
记得有一句话是这么说的:注释的最高境界——代码即注释。
当然了,这也不是说,我们不应该写注释。只是注释要写对地方。
小结
到这里所有的“坏味道”已经讲完了。平常我们在写代码的时候,一定要注意这些坏味道。
“如果尿布臭了,就换掉它”。这句话同样适用于我们的代码。
“代码的坏味道”的系列文章主要是对常见的22种坏味道的了解和熟悉,以促使我们在开发过程中,能够经常性地分析和思考程序,寻找已经散发出坏味道的地方并对其进行适当重构,使得代码更加“漂亮”。
在后续的文章中,我会介绍一系列的重构手法来消除这些坏味道。
To Be Continued...