我读了一些其他程序员编写的代码，他为应用程序做了一些设计，应用程序类相互派生出来：
public interface IABase
{
}
class BBase : IABase
{
}
class CDesktop : BBase
{
}
class Report : CDesktop
{
}
class Sample : Report
{
}
这种设计是反模式的吗？我必须首先告诉它，它真的很难理解类和应用逻辑的关系，这是我的2美分。还有什么可以说的？
答案 0 :(得分：3)
有一些一般性的建议，更喜欢组合而不是继承。经常被吹捧的优势在于它更灵活，并且更能阻止紧密耦合。 （有关此问题的讨论，请参阅where-does-this-concept-of-favor-composition-over-inheritance-come-from，DeepClassHierarchies，deep-class-inheritance-hierarchy-bad-idea，long-inheritance-hierarchy等。
特别是对于C＃，值得注意的是组合可能需要相当多的样板 - 毕竟，如果你想暴露组件/基类的大部分功能，那么你需要手动公开它;继承（相比之下）使得暴露一切变得非常容易。
在有疑问时谨慎使用继承可能是一个好主意，因为否则很容易创建大量紧密耦合的spagetti-monsters。但是有些情况下经典的动态调度和所有需要的东西;并且还存在这样的情况：即使你的概念更好地映射到一种关系而不是一种关系，构成的冗长也是一个相当大的负担。
因此，虽然这种代码难以维护，但有时仍然值得。您的具体示例看起来层次结构不必要地深入;然而，旧代码增加一些疣是正常的 - 如果这是最糟糕的，请认为自己很幸运。