重构-改善代码的既有设计-代码的坏味道（3-2）

3.11.平行继承体系（Parallel Inheritance Hierarchies）

3.12.冗赘类（Lazy Class）

如果重构使得类的身价严重缩水，不再做那么多工作。或者，开发者事前规划了某些变化，并添加一个类来应付这些变化，但变化实际为发生。请删除这些类。

如果某些子类没有足够的工作，试试 Collapse Hierarchy.对于几乎没用的组件，你应该以Inline Class对付它们。

3.13.夸夸其谈未来性（Speculative Generality）

3.14.令人迷惑的暂时字段（Temporary Field）

3.15.Message Chains（过度耦合的消息链）

3.16.中间人（Middle Man）

3.17.狎昵关系 (Inappropriate Intimacy）

过分狎昵的类必须拆散。可以采用Move Method和Move Field帮它们划清界限，以减少狎昵行为。也可以看看是否可以运用 Change Bidirectional Association to Unidirectional让其中一个类对另一个类斩断情丝。如果两个类实在情投意合，可以运用Extract Class把两者共同点提炼的一个安全地点，让他们坦荡的使用这个新类。或者也可以尝试运用Hide Delegate让另一个类来为它们传递相思情。

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

3.18.异曲同工的类（Alternative Classes with Different Interfaces）

3.19.不完美的库类（Incomplete Library Class）

3.20.纯稚的数据类（Data Class）

3.21.被拒绝的遗赠（Refused Bequest）

3.22.过多的注释（Comments）

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

当你感觉需要注释代码时，请先尝试重构，试着让所有注释都变得多余。完成重构之后常常会发现，注释已经变得多余，因为代码已经清楚说明了一切。

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

最后

以上就是美满小松鼠为你收集整理的重构-改善代码的既有设计-代码的坏味道（3-2）的全部内容，希望文章能够帮你解决重构-改善代码的既有设计-代码的坏味道（3-2）所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。