《重构改善既有代码的设计》之代码的坏味道（三）

十一、Parallel Inheritance Hierarchies(平行继承体系)

    Prallel Inheritance Hierarchies其实是Shotgun Surgery的特殊情况。在这种情况下，每当你为某个类增加ige子类，必须也为另一个类相应增加一个子类。如果你发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，便是闻到了这种坏味道。

    消除这种坏味道的策略是：让一个继承体系的实例引用另一个继承体系的实例。如果再接再厉运用Move Method和Move Field，就可以将引用端的继承体系消弭于无形。

十二、Lazy Class(冗赘类)

    你所创建的每一个类，都得有人去理解它、维护它，这些工作都是要花钱的。如果一个类的所得不值其身价，它就应该消失。

十三、Speculative Generality(夸夸其谈未来性)

    这个令我们十分敏感的坏味道，命名者是Brian Foote。当有人说“噢，我想我们总有一天需要做这事”，并因而企图以各式各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道便出现了。那么做的结果往往造成系统更难理解和维护。如果所有装置都会被用到，那就值得那么做；如果用不到，就不值得。用不上的装置只会挡你的路，所以，把它搬开吧。

十四、Temporary Field(令人迷惑的暂时字段)

    有时你会看到这样的现象：其内某个实例变量仅仅为某种特定情况而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有变量。在变量未被使用的情况下猜测当初其设置的目的，会让你发疯的。

    如果类中有一个复杂算法，需要好几个变量，往往就可能导致Temeprary Field的出现。又要实现着不希望传递一长串参数，所以他把这些参数都放进字段中。但是这些字段只在使用该算法的时候才有效，其他情况下只会让人迷惑。这时候你可以利用Extract Class把这些变量和其相关函数提炼到一个独立类中。提炼后的新对象将是一个函数对象。

十五、Message Chains(过度耦合的消息链)

    如果你看到一个用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象。。。这就是消息链实际代码中你看到的可能是一长串getThis()或一长串临时变量。采取这种方式，意味客户端代码将与查找过程中的导航紧密耦合。一旦对象间的关系发生任何变化，客户端不得不做出想要修改。

十六、Middle Man(中间人)

    对象的基本特征之一就是封装--对外部世界隐藏其内部细节。封装往往伴随着委托。

    但是人们可能会过度运用委托。你也许会看到某个类接口有一半的函数都委托给其他类，这样就是过度运用。

十七、Inappropriate Intimacy(狎昵关系)

    有时你会看到两个类过于亲密，花费太多时间去探究彼此的private成分。如果这发生在两个 “人”之间，我们不必做卫道士；但对于类，我们希望它们严守清规。

    继承往往造成过度亲密，因为子类对超类的了解总是超过后者的主观愿望。如果你觉得该让这个孩子独自生活了，请运用Replace Inheritance With Delegation让它离开继承体系。

十八、Alternative Classes With Different Interfaces(异曲同工的类)

    如果两个函数做同一件事，却有着不同的签名，请运用Rename Method根据它们的用途重新命名。但这往往不够，请反复运用Move Method将某些行为移入类，直到两者的协议一致为止。如果你必须重复而赘余地移入代码才能完成这些，或许可运用Extract Superclass为自己赎点罪。

十九、Incomplete Library Class(不完美类库)

二十、Data Class(纯稚的数据类)

    所谓Data Class是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长处。这样的类只是一种不会说话的容器，它们几乎一定被其他类过分细琐的操纵着。

二十一、Refused Bequest(被拒绝的遗赠)

    如果子类复用了超类的行为，却又不愿意支持超类的接口，Refused Bequest的坏味道就会变得浓烈。拒绝继承超类的实现，这一点我们不介意；但如果拒绝超类的接口，我们不以为然。不过即使你不愿意继承接口，也不用胡乱修改继承体系，应该运用Replace Inheritance With Delegation来达到目的。

二十二、Comments(过多的注释)

    但担心，我们并不是说你不该写注释。但是常常会有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。这种情况的发生次数之多，实在令人吃惊。

    如果你需要注释来解释一块代码做了什么，试试Extract Method；如果函数已经提炼出来，但还是需要注释来解释其行为，试试Rename Method；如果你需要注释说明某些系统的需求规格，试试Introduce Assertion。

    如果你不知道该做什么，这才是注释的良好时机。除了用来记述将来的打算之外，注释还可以用来标记你并无十足把握的区域。你可以在注释里写下自己“为什么做某件事”。这类信息可以帮助将来的修改者，尤其是那些健忘的家伙。

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