代码重构之道(三)
作者:互联网
夸夸其谈未来性
企图以各种各样的钩子和特殊情况来处理一些非必要的事情,这种坏味道就出现了。如果用到了那就值得去做,如果用不到那就不值得,只会挡你的路,所以把它挪开吧。
如果你的某个抽象类其实没有起到太大的作用,函数上的某些参数未被使用…可以移除它们了。
概念:
钩子就是留一个接口,暂时不实现,作为未来的扩展用。
这里主要讲的是钩子的坏处,如果不需要的,就直接删掉吧。
令人迷惑的暂时字段
某个实例变量仅为某种特定的情况而设。这样的代码让人不易理解。在变量未被使用的情况下猜测当初其设置目的,会让你发疯的。
-
没用到的变量记得删除、
-
哪里用到就去哪里声明。
本质上以上两点,都是为了可读性。
过度耦合消息链
如果你看到用户向一个对象请求另一个对象,然后再向后者请求另一个对象,然后再请求另个一对象…这就是消息链。采用这种方式,意味着客户代码将与查找过程中的导航结构紧密耦合。一旦对象间的关系发生任何变化,客户端就不得不做出相应的修改。
解释:
A调用B,B调用C,C调用D
如果此时我修改了D ,那ABC三个类都要做适配。
中间人
封装往往伴随着委托。你也许会看到某个类接口有一半的函数都委托给其他类,这样就是过度运用。
主体调用外部,不要太过度。比如我类A写了三行,调用类B,类B里100行。
狎昵关系
有时会看到两个类过于亲密,话费太多的时间去探究彼此的private成分。过分狎昵的类必须拆散,帮它们划清界线,从而减少狎昵行径。
继承往往造成过度亲密,因为子类对超类的了解总是超过后者的主观愿望。如果你觉得该让孩子独立生活了,让他离开继承。
异曲同工的类
两个函数做同一件事,却有着不同的签名。
这其实就是代码冗余,很多代码很多类,干着重复或者差不多的事情。
比如联合开发中,两个人写的都是同样的功能,差不多的代码,但是两人之间并未沟通,所以整个工程中,可能出现相同功能的重复代码。
造成:
- 影响阅读
- 代码冗余 结构冗余
- 容易造成bug
- 迭代困难 维护困难
不完美的类库
类库函数构造的不够好,又不能修改它们:
- 如果只想修改类的一两个函数,可以引入外加函数。
- 如果想要添加一大堆额外行为,建立一个新类包含这些额外行为,让其成为子类。
当你准备去在一个类的基础上做修改时,且改动比较大。比如原类50行,你改动后预估有200行,也就是说改动很大。这时候最好采用继承。
这样的好处就是:
- 不影响原类的原子性
- 不影响其他类对原类的调用
- 优化代码结构
标签:重构,调用,原类,代码,之道,如果,狎昵,冗余 来源: https://blog.csdn.net/GBS20200720/article/details/122768565