代码重构之道（三）

夸夸其谈未来性

企图以各种各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道就出现了。如果用到了那就值得去做，如果用不到那就不值得，只会挡你的路，所以把它挪开吧。

如果你的某个抽象类其实没有起到太大的作用，函数上的某些参数未被使用…可以移除它们了。

概念：

钩子就是留一个接口，暂时不实现，作为未来的扩展用。

这里主要讲的是钩子的坏处，如果不需要的，就直接删掉吧。

令人迷惑的暂时字段

某个实例变量仅为某种特定的情况而设。这样的代码让人不易理解。在变量未被使用的情况下猜测当初其设置目的，会让你发疯的。

• 没用到的变量记得删除、

• 哪里用到就去哪里声明。

本质上以上两点，都是为了可读性。

过度耦合消息链

如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另个一对象…这就是消息链。采用这种方式，意味着客户代码将与查找过程中的导航结构紧密耦合。一旦对象间的关系发生任何变化，客户端就不得不做出相应的修改。

解释：

A调用B，B调用C，C调用D

如果此时我修改了D ，那ABC三个类都要做适配。

中间人

封装往往伴随着委托。你也许会看到某个类接口有一半的函数都委托给其他类，这样就是过度运用。

主体调用外部，不要太过度。比如我类A写了三行，调用类B，类B里100行。

狎昵关系

有时会看到两个类过于亲密，话费太多的时间去探究彼此的private成分。过分狎昵的类必须拆散，帮它们划清界线，从而减少狎昵行径。

继承往往造成过度亲密，因为子类对超类的了解总是超过后者的主观愿望。如果你觉得该让孩子独立生活了，让他离开继承。

异曲同工的类

两个函数做同一件事，却有着不同的签名。

这其实就是代码冗余，很多代码很多类，干着重复或者差不多的事情。

比如联合开发中，两个人写的都是同样的功能，差不多的代码，但是两人之间并未沟通，所以整个工程中，可能出现相同功能的重复代码。

造成：

• 影响阅读
• 代码冗余 结构冗余
• 容易造成bug
• 迭代困难 维护困难

不完美的类库

类库函数构造的不够好，又不能修改它们：

1. 如果只想修改类的一两个函数，可以引入外加函数。
2. 如果想要添加一大堆额外行为，建立一个新类包含这些额外行为，让其成为子类。

当你准备去在一个类的基础上做修改时，且改动比较大。比如原类50行，你改动后预估有200行，也就是说改动很大。这时候最好采用继承。

这样的好处就是：

• 不影响原类的原子性
• 不影响其他类对原类的调用
• 优化代码结构