Question

我目前正在开发一个asp.net网站，由其他人完成，而且它的工作非常复杂......我想是的！几乎每个类都继承自另一个类，然后是另一个类，另一个继续等等......你必须平均大约8/10级才能获得基类，有时更多！而且这些类中还有其他类，它们遵循相同的Uber Inheritence模式。这让我在代码中丢失很多次，导致上帝知道在视觉工作室打开了多少标签。

这是好的/正常的做法还是不好的做法？我认为这是不好的做法，因为过于复杂的使用继承会导致代码不可扩展的东西变得如此简单...............但我可能是错的：）

谢谢！

Answer 1

是的，过度使用继承可能会导致意大利面仓库。继承是一种允许封装和抽象的工具。滥用它会导致过多的抽象，然后代码的目的变得无法使用。我已经看到这种模式在命令式构造中被滥用，其中方法在实际应用动作之前从方法传递到方法。

private bool getData()
{
    return getOtherData();
}

private bool getOtherData()
{
    return getSomeExtraData();
} 

private bool getSomeExtraData()
{
    return SeeHowTediousThisIs();
}

一切正常，但它只是一个非常糟糕的维护架构。我发现这经常发生在试图引入复杂性的顾问/承包商（再：工作保障）。

Answer 2

有一个设计指南“赞成合成而不是继承”8-10级继承中断有点。

http://en.wikipedia.org/wiki/Composition_over_inheritance

Answer 3

听起来像继承过度，很少需要超过2-3级，这将是一个复杂的商业模式。

这些是什么类？控制？ Business Objects？它们是否在任何地方都有文档记录（UML），以便您可以很好地了解模型？

8-10级深度很多，我猜测这些类是在（或从未）设计之前编码的。

Answer 4

继承作为重用代码的手段确实是一个非常糟糕的选择。考虑到基于.NET的语言中的每个类都有一个单个继承槽，代码可以在其中进行。因此，对于每个班级，应该明智地选择它是否应该继承其他东西。

经典地说，继承描述了 “is-a” 关系，通过上传继承链，我们达到了更高的抽象级别。

第一个问题应该始终是 “can-act-as” 关系是否足够。在这种情况下，通过接口描述关系通常是更好的选择。其次，在添加抽象时，问题必须是不可忽略的代码量是否可以与这些抽象一起使用以满足您正在寻找的功能。

如果几乎没有任何代码使用这些抽象，那么它们本身很可能毫无价值。同样，接口的抽象成本通常低于基类。

所以，总结

“can-act-as”关系通常就足够了 - 你不需要去寻求“is-a”关系
继承槽很珍贵 - 它只能使用一次。
代码重用的方法比继承类
基类和接口是抽象：确保您的代码确实可以使用它们。如果您的接口只由一个类实现，那么您的抽象可能毫无价值，并且在必要时可以轻松引入。
如果需要抽象，接口上的惩罚要低于基类。

Answer 5

我肯定最近一直在挖掘继承地狱。我们确实拥有看起来像这样的代码

 Public Class A
   ' Do Stuff, methods, members, etc.
     Public var As Object

     Public Sub New()
         member = New Object
     End Sub
 End Class

 ' yes it's empty
 Public Class B : Inherits A
 End Class

 ' yes it's empty
 Public Class C : Inherits A
     Public Sub New()
         MyBase.New()
         member.SomeMethod()
     End Sub
 End Class

然后是Base类，其中包含必须继承的对象列表，以便将对象添加到该列表中。

简而言之，是的，继承可以被滥用，就像一切一样。对我来说最大的帮助就是找到一个很好的UML建模工具来反向设计你正在使用的语言。

是否有可能在代码中丢失过继承？

5 个答案: