我遇到了许多反对在 C# 中包含多重继承的论点，其中一些包括（撇开哲学论点）：
我来自 C++ 背景，怀念多重继承的强大和优雅。尽管它并不适合所有软件设计，但在某些情况下，很难否认它对接口、组合和类似的 OO 技术的实用性。
排除多重继承是否意味着开发人员不够聪明，无法明智地使用它们，并且无法在复杂性出现时解决它们？
我个人很欢迎在 C#（可能是 C##）中引入多重继承。
附录：我很想知道来自单一（或程序背景）与多重继承背景的回复。我经常发现没有多重继承经验的开发人员通常会默认使用多重继承是不必要的论点，因为他们没有任何范式经验。
【问题讨论】：
标签： c# inheritance multiple-inheritance
我说不，直到钻石问题（类的多重继承不好的一个重要原因）得到充分解决并且解决方案与使用接口一样好。简而言之，钻石问题基本上与由于类的多重继承而导致类中的数据、方法和事件的潜在歧义有关。
P/S 您“很少”避免使用您急需的编程解决方案，因为它很难。 “困难”不是没有多重继承的借口。多线程很难，但它在 C# 中可用。没有多重继承的一大原因是由于菱形问题（http://en.wikipedia.org/wiki/Diamond_problem）。一个类似的推理适用于您对更好的替代方案的评论（人们以不同的方式解决和思考，所以有时一个解决方案是一个坏主意）和合适的选项已经存在（为什么在 ADO.NET 成功并且成熟时创建 LINQ...由于一个比另一个强。）
【讨论】：
我几乎不会错过 C# 中的多重继承。
如果您使用多重继承来定义实际的域模型，那么根据我的经验，您通常可以使用单一继承和一些好的设计模式来创建同样好的设计。
我发现多重继承具有真正价值的大部分地方不是域本身，而是一些需要您使用 MI 的技术/框架约束。使用 ATL 实现 COM 对象是一个很好的例子，说明您使用多重继承来实现 COM 对象所需的所有必要接口，并且是对丑陋（与 .NET 相比）技术的优雅解决方案。从优雅的角度来看，它是一个 C++ 框架！
我现在有一种情况，我可以使用多重继承。我有一个类需要从其他域对象派生功能，但它也需要可用于跨 AppDomain 调用。这意味着它必须从 MarshalByRefObject 继承。所以在这种特殊情况下，我真的很想从 MarshalByRefObject 和我的特定域对象中派生。然而这是不可能的，所以我的类必须实现与我的域对象相同的接口，并将调用转发到聚合实例。
但正如我所说，这是技术/框架施加约束的情况，而不是领域模型本身。
【讨论】：
如果接口可以实现的话，它会让事情变得更简单，更少的代码。但是它们会被误用而不是正确使用吗？我认为，在您看到如何正确完成之前，您不会错过它。我对多重继承不安全的论点感到恼火。它不是。但几乎所有的语言实现都是。但我们需要它吗？，我不知道。
我更喜欢返回类型协方差，这可以很容易地添加（只需放宽规则，在覆盖方法的返回类型上），并且始终是安全的。
示例：
class shape {}
class circle : shape {}
interface part {
shape Form();
}
interface wheel : part {
circle Form();
}
【讨论】：
IFoo）指定静态类（例如IFooHelpers）如果在编译类C时实现该接口会有什么问题编译器找不到成员的实现（例如int DoSomething(string Bar)，它应该自动生成代码int IFoo.DoSomething(string Bar) {return IFooHelpers.Classes<C>.DoSomething(C This, string Bar);}，假设存在适当的静态类和方法。
接口是多重继承。事实上，我认为 Java/C# 类型接口是多重继承的“正确”实现。通过使用接口强制进行多重继承，而不是允许从多个具体或抽象类继承，这会迫使开发人员使用组合/委托来进行代码重用。继承永远不应该用于代码重用，C++ 类型多重继承的缺失迫使开发人员想出设计更好的类。
【讨论】：