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

版权声明:不自见故明;不自是故彰;不自伐故有功;不自矜故长; https://blog.csdn.net/LightUpHeaven/article/details/84622193

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。

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

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

猜你喜欢

转载自blog.csdn.net/LightUpHeaven/article/details/84622193