blocks|key|3362694|text|我从来没有错过过一次，从来没有。是的，it+MI变得复杂，是的，接口在许多方面做了类似的工作-但这并不是最大的问题:在一般意义上，大多数时候根本不需要它。在许多情况下，即使是单一继承也被过度使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3362695|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I've never missed it once, not ever. Yes, it [MI] gets complicated, and yes, interfaces do a similar job in many ways - but that isn't the biggest point: in the general sense, it simply isn't needed most of the time. Even single inheritance is overused in many cases.

blocks|key|3149828|text|我认为如果没有提供足够的ROI，它会使事情变得过于复杂。我们已经看到人们用太深的继承树来屠宰.NET代码。我可以想象，如果人们有能力进行多重继承，那会是多么的残暴。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3149829|我不否认它有潜力，但我只是看不到足够的好处。|3149830|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I think it would over-complicate things without providing enough ROI. We already see people butcher .NET code with too-deep inheritance trees. I can just imagine the atrocities if people had the power to do multiple inheritance.

I won't deny that it has potential, but I just don't see enough benefit.

blocks|key|3362734|text|C#支持单继承、接口和扩展方法。在它们之间，它们提供了多重继承提供的几乎所有东西，而没有多重继承带来的令人头疼的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3362735|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

C# supports single inheritance, interfaces and extension methods. Between them, they provide just about everything that multiple inheritance provides, without the headaches that multiple inheritance brings.

blocks|key|360460|text|我反对多重继承仅仅是因为你所说的原因。开发人员会滥用它。我已经看到了从实用程序类继承的每个类的足够多的问题，所以你可以从每个类调用一个函数，而不需要输入太多类型，知道在许多情况下多重继承会导致糟糕的代码。同样的事情也适用于GoTo，这也是为什么它的使用如此不受欢迎的原因之一。我认为多重继承确实有一些很好的用法，就像GoTo一样，在理想的世界中，它们都只在适当的时候使用，不会有问题。然而，这个世界并不理想，所以我们必须保护糟糕的程序员不受他们自己的影响。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360461|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would argue against multiple inheritance simply for the reason you state. Developers will misuse it. I've seen enough problems with every class inheriting from a utility class, just so you can call a function from every class without needing to type so much, to know that multiple inheritance would lead to bad code in many situations. The same thing could be said about GoTo, which is one of the reasons it's use is so frowned upon. I think that multiple inheritance does have some good uses, just like GoTo, In an ideal world, where they were both only used when appropriately, there would be no problems. However, the world is not ideal, so we must protect bad programmers from themselves.

blocks|key|361166|text|虽然在某些情况下它确实很有用，但我发现大多数时候，当我认为我需要它时，我真的不需要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361167|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

While there are certainly instances where it can be useful, I have found that most of the time when I think I need it, I really don't.

blocks|key|3149900|text|自从C#作为alpha/beta版本首次发布以来，我就一直在使用它，并且从未错过过多重继承。MI对于某些事情来说是不错的，但几乎总是有其他方法来实现相同的结果(其中一些方法实际上最终会更简单，或者创建一个更容易理解的实现)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3149901|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I have been working with C# since it was first available as an alpha/beta release and have never missed multiple inheritance. MI is nice for some things but there are almost always other ways to achieve the same result (some of which actually end up being simpler or creating an easier to understand implementation).

blocks|key|3362815|text|更喜欢聚合而不是继承！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3362816|class+foo+:+bar,+baz|code-block|syntax|javascript|3362817|通常可以更好地处理|3362818|class+foo+:+Ibarrable,+Ibazzable
{
++...+
++public+Bar+TheBar{+set+}
++public+Baz+TheBaz{+set+}

++public+void+BarFunction()
++{
+++++TheBar.doSomething();
++}
++public+Thing+BazFunction(+object+param+)
++{
++++return+TheBaz.doSomethingComplex(param);
++}
}|3362819|这样，您就可以换入换出IBarrable和IBazzable的不同实现，以创建应用程序的多个版本，而无需编写另一个类。|3362820|依赖注入对此有很大的帮助。|3362821|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Prefer aggregation over inheritance!

<pre><code>class foo : bar, baz
</code></pre>

is often better handled with

<pre><code>class foo : Ibarrable, Ibazzable
{
 ... 
 public Bar TheBar{ set }
 public Baz TheBaz{ set }

 public void BarFunction()
 {
 TheBar.doSomething();
 }
 public Thing BazFunction( object param )
 {
 return TheBaz.doSomethingComplex(param);
 }
}
</code></pre>

This way you can swap in and out different implementations of IBarrable and IBazzable to create multiple versions of the App without having to write yet another class.

Dependency injection can help with this a lot.

blocks|key|3362841|text|多重继承通常是有用的，许多OO语言以某种方式实现它(C%2B%2B、Eiffel、CLOS、Python...)。这是必要的吗？不是的。有这样的感觉很好吗？是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3362842|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Multiple inheritance in general can be useful and many OO languages implement it one way or another (C++, Eiffel, CLOS, Python...). Is it essential? No. Is it nice to have? Yes.

blocks|key|359161|text|更新|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|359162|我向所有投票反对我的人提出挑战，让他们向我展示我不能轻易移植到单继承语言的多重继承示例。除非任何人能展示任何这样的样本，否则我声称它不存在。我已经将大量的C%2B%2B代码(+MH+)移植到了Java+(+no+-MH)，无论C%2B%2B代码使用了多少MH，这从来都不是问题。|359163|359164|到目前为止，没有人能证明多重继承比你在文章中提到的其他技术具有any+advantage+(使用接口和委托，我可以在没有太多代码或开销的情况下获得完全相同的结果)，同时它也有一些众所周知的缺点(diamond+problem是最烦人的)。|359165|实际上，多重继承通常被滥用。如果您使用OO设计以某种方式将现实世界建模为类，您将永远不会达到多重继承真正有意义的地步。你能为多重继承提供一个有用的例子吗？到目前为止，我看到的大多数例子实际上都是“错误的”。它们使一些东西成为一个子类，这实际上只是一个额外的属性，因此实际上是一个接口。|359166|看看Sather吧。它是一种编程语言，其中接口确实有多重继承，为什么不是(它不会产生菱形问题)，然而没有接口的类没有任何继承。它们只能实现接口，并且可以“包含”其他对象，这使得这些其他对象成为它们的固定部分，但这与继承不同，它更像是一种委托形式(通过包含对象“继承”的方法调用实际上只是转发给封装在对象中的这些对象的实例)。我认为这个概念非常有趣，它表明你可以拥有一个完全干净的OO语言，而不需要任何实现继承。|359167|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Multiple_inheritance#Criticisms|1|http://en.wikipedia.org/wiki/Diamond_problem|2|http://www.icsi.berkeley.edu/~sather/^0|0|2|0|0|0|V|D|0|2P|F|1|0|0|2|6|2|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|14|8|@]|D|@]|E|$]]|$1|I|3|J|5|6|7|15|8|@]|D|@$9|16|A|17|1|18]|$9|19|A|1A|1|1B]]|E|$]]|$1|K|3|L|5|6|7|1C|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|1D|8|@]|D|@$9|1E|A|1F|1|1G]]|E|$]]|$1|O|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]|W|$5|R|S|T|E|$U|X]]|Y|$5|R|S|T|E|$U|Z]]]]

Update 
I challenge everyone who votes me down to show me any example of multiple inheritance that I can't easily port to a language with single inheritance. Unless anyone can show any such sample, I claim it does not exist. I have ported tons of C++ code (MH) to Java (no-MH) and that was never a problem, no matter how much MH the C++ code used.

<hr>

Nobody could ever prove so far that multiple inheritance has <a href="http://en.wikipedia.org/wiki/Multiple_inheritance#Criticisms" rel="nofollow noreferrer">any advantage</a> over other techniques you mentioned in your post (using interfaces and delegates I can get exactly the same result without much code or overhead), while it has a couple of well known disadvantages (<a href="http://en.wikipedia.org/wiki/Diamond_problem" rel="nofollow noreferrer">diamond problem</a> being the most annoying ones).

Actually multiple inheritance is usually abused. If you use OO design to somehow model the real world into classes, you will never get to the point where multiple inheritance makes actually sense. Can you provide a useful example for multiple inheritance? Most of the examples I've seen so far are actually "wrong". They make something a subclass, that is in fact just an extra property and thus actually an interface.

Take a look at <a href="http://www.icsi.berkeley.edu/~sather/" rel="nofollow noreferrer">Sather</a>. It is a programming language, where interfaces do have multiple inheritance, as why not (it can't create a diamond problem), however classes that are no interfaces have no inheritance whatsoever. They can only implement interfaces and they can "include" other objects, which makes these other objects a fixed part of them, but that is not the same as inheritance, it's rather a form of delegation (method calls "inherited" by including objects are in fact just forwarded to instances of these objects encapsulated in your object). I think this concept is pretty interesting and it shows you can have a complete clean OO language without any implementation inheritance at all.

blocks|key|363828|text|一位同事写了一篇关于如何在动态编译的C#中获得类似多重继承的东西的博客：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363829|http://www.atalasoft.com/cs/blogs/stevehawley/archive/2008/09/29/late-binding-in-c-using-dynamic-compilation.aspx|offset|length|363830|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|35|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

A colleague wrote this blog about how to get something like multiple inheritance in C# with Dynamic Compilation:

<a href="http://www.atalasoft.com/cs/blogs/stevehawley/archive/2008/09/29/late-binding-in-c-using-dynamic-compilation.aspx" rel="nofollow noreferrer">http://www.atalasoft.com/cs/blogs/stevehawley/archive/2008/09/29/late-binding-in-c-using-dynamic-compilation.aspx</a>

blocks|key|360527|text|编号：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|360528|(用于投票)|360529|entityMap^0|0|3|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

No.

(for voting)

blocks|key|3150020|text|我认为这真的很简单。就像任何其他复杂的编程范例一样，您可能会滥用它并伤害自己。你可以滥用对象(哦，是的！)，但这并不意味着OO本身就不好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150021|MI也是如此。如果你没有一个很大的继承类的“树”，或者没有很多提供相同命名方法的类，那么你完全可以使用MI。事实上，由于MI提供了实现，因此通常比SI实现更好，在SI实现中，您必须重新编码，或者将方法剪切并粘贴到委托对象。在这些情况下，代码越少越好。如果你试图通过接口继承重用对象，你可能会把共享代码搞得一团糟。而且这样的变通方法闻起来不太对劲。|3150022|我认为.NET的单继承模型是有缺陷的:它们应该只使用接口，或者只使用MI。拥有“一半和一半”(即单一实现继承加上多接口继承)比它应该的更令人困惑，而且一点也不优雅。|3150023|我来自MI的背景，我并不害怕它，也不会被它灼伤。|3150024|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I think its simple really. Just like any other complex programming paradigm, you can misuse it and hurt yourself. Can you misuse objects (oh yes!), but that doesn't mean OO is bad in itself.

Similarly with MI. If you do not have a large 'tree' of inherited classes, or a lot of classes that provide the same named methods, then you will be perfectly fine with MI. In fact, as MI provides the implementation, you'll often be better off than a SI implementation where you have to re-code, or cut&amp;paste methods to delegated objects. Less code is better in these cases.. you can make an almighty mess of sharing code by trying to re-use objects through interface inheritance. And such workarounds don't smell right.

I think the single-inheritance model of .NET is flawed: they should have gone with interfaces only, or MI only. Having "half and half" (ie single implementation inheritance plus multiple interface inheritance) is more confusing than it should be, and not elegant at all.

I come from a MI background, and I'm not scared of or burnt by it.

blocks|key|359174|text|我已经在这里贴了几次了，但我只是觉得它真的很酷。你可以学习如何伪造MI+here。我还认为这篇文章强调了为什么MI是如此痛苦，即使这不是故意的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|359175|我既不怀念它，也不需要它，我更喜欢使用对象的组合来实现我的目的。这也是这篇文章的重点。|359176|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codeproject.com/KB/architecture/smip.aspx^0|10|4|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

I have posted this here a couple of times but I just think it is really cool. You can learn how to fake MI <a href="http://www.codeproject.com/KB/architecture/smip.aspx" rel="nofollow noreferrer">here</a>. I also think the article highlights why MI is such a pain even if that was not intended.

I neither miss it or need it, I prefer to use composition of objects to achieve my ends. That is really the point of the article as well.

blocks|key|3362949|text|下面是我经常遇到的一个非常有用的多重继承案例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3362950|作为一个工具包供应商，我不能更改已发布的API，否则我会破坏向后兼容性。由此导致的一件事是，一旦我发布了接口，我就再也不能添加它了，因为它会破坏任何实现它的人的编译--唯一的选择就是扩展接口。|3362951|这对现有客户来说很好，但新客户会认为这个层次结构不必要地复杂，如果我从一开始就设计它，我不会选择以这种方式实现它--我必须这样做，否则我将失去向后兼容性。如果接口是内部的，那么我只需添加它并修复实现器。|3362952|在许多情况下，接口的新方法有一个明显的小的默认实现，但我不能提供它。|3362953|我更喜欢使用抽象类，然后当我必须添加一个方法时，添加一个具有默认实现的虚拟方法，有时我们会这样做。|3362954|当然，问题是如果这个类很可能与已经在扩展的东西混合在一起--那么我们别无选择，只能使用接口并处理扩展接口。|3362955|如果我们认为这个问题很严重，我们会选择富事件模型--我认为这在C#中可能是正确的答案，但并不是所有问题都是以这种方式解决的--有时您需要一个简单的公共接口，而扩展程序需要一个更丰富的接口。|3362956|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

Here is a very useful case for multiple inheritance that I run into all of the time. 

As a toolkit vendor, I cannot change published API's or I will break backwards compatibility. One thing that results from that is that I cannot ever add to an interface once I have released it because it would break compilation for anyone implementing it -- the only option is to extend the interface. 

This is fine for existing customers, but new ones would see this hierarchy as needlessly complex, and if I were designing it from the beginning, I would not opt to implement it this way -- I have to, or else I will lose backwards compatibility. If the interface is internal, then I just add to it and fix the implementors.

In many cases, the new method to the interface has an obvious and small default implementation, but I cannot provide it.

I would prefer to use abstract classes and then when I have to add a method, add a virtual one with a default implementation, and sometimes we do this.

The issue, of course, is if this class would likely be mixed in to something that is already extending something -- then we have no choice but to use an interface and deal with extension interfaces.

If we think we have this problem in a big way, we opt for a rich event model instead -- which I think is probably the right answer in C#, but not every problem is solved this way -- sometimes you want a simple public interface, and a richer one for extenders.

blocks|key|360598|text|我自己也在C%2B%2B中使用过多重继承，但你真的必须知道你在做什么才不会给自己带来麻烦，特别是当你有两个共享祖辈的基类的时候。然后你可以进入虚拟继承的问题，必须声明你要调用的每个构造函数(这使得二进制重用变得更加困难)……它可以是一团糟。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360599|更重要的是，CLI当前的构建方式阻碍了MI的轻松实现。我确信如果他们愿意的话，他们可以做到这一点，但我更愿意在CLI中看到其他事情，而不是多重继承。|360600|我希望看到的包括Spec#的一些特性，比如不可为空的引用类型。我还希望能够将参数声明为const，并能够声明函数const+(这意味着您可以保证对象的内部状态不会被方法和编译器双重检查)，从而看到更多的对象安全性。|offset|length|360601|我认为在单继承、多接口继承、泛型和扩展方法之间，你可以做任何你需要做的事情。如果有任何东西可以改善渴望MI的人的事情，我认为某种类型的语言构造将允许更容易的聚合和组合是必要的。这样，您可以拥有一个共享接口，但随后将您的实现委托给您通常继承自的类的私有实例。现在，这需要大量的样板代码来完成。拥有一个更自动化的语言功能将会有很大的帮助。|360602|entityMap|0|LINK|mutability|MUTABLE|url|http://research.microsoft.com/SpecSharp/^0|0|0|8|5|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$F|U|G|V|1|W]]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

I've used multiple inheritence in C++ myself too, but you really have to know what you're doing in order to not get yourself in trouble, especially if you have two base classes which share a grandparent. Then you can get into issues with virtual inheritence, having to declare every constructor you're going to call down the chain (which makes binary reuse much harder)... it can be a mess.

More importantly, the way the CLI is currently built precludes MI from being implemented easily. I'm sure they could do it if they wanted, but I have other things I'd rather see in the CLI than multiple inheritence.

Things I'd like to see include some features of <a href="http://research.microsoft.com/SpecSharp/" rel="nofollow noreferrer">Spec#</a>, like non-nullable reference types. I'd also like to see more object safety by being able to declare parameters as const, and the ability to declare a function const (meaning that you are guaranteeing that the internal state of an object won't be changed by the method and the compiler double checks you).

I think that between Single Inheritence, Multiple Interface Inheritence, Generics, and Extension Methods, you can do pretty much anything you need to. If anything could improve things for someone desiring MI, I think some sort of language construct which would would allow easier aggregation and composition is needed. That way you can have a shared interface, but then delegate your implementation to a private instance of the class you would normally inherit from. Right now, that takes a lot of boiler plate code to do. Having a more automated language feature for that would help significantly.

blocks|key|360654|text|据我所知，CLR不支持多重继承，所以我怀疑它能否像C%2B%2B+(或Eiffel，考虑到该语言是专门为MI设计的)那样以一种有效的方式支持它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360655|多重继承的一个很好的替代方法是称为特征。它允许您将不同的行为单元混合到一个类中。编译器可以支持将特征作为单继承类型系统的编译时扩展。您只需声明类X包括特征A、B和C，然后编译器将您所要求的特征放在一起以形成X的实现。|360656|例如，假设您正在尝试实现IList(of+T)。如果您查看IList(of+T)的不同实现，您会发现它们通常共享一些完全相同的代码。这就是我们需要的特点。您只需使用其中的公共代码声明一个特征，就可以在IList(of+T)的任何实现中使用该公共代码--即使该实现已经有一些其他基类。语法可能如下所示：|360657|///+This+trait+declares+default+methods+of+IList<T>
public+trait+DefaultListMethods<T>+:+IList<T>
{
++++//+Methods+without+bodies+must+be+implemented+by+another+
++++//+trait+or+by+the+class
++++public+void+Insert(int+index,+T+item);
++++public+void+RemoveAt(int+index);
++++public+T+this[int+index]+{+get;+set;+}
++++public+int+Count+{+get;+}

++++public+int+IndexOf(T+item)
++++{
++++++++EqualityComparer<T>+comparer+=+EqualityComparer<T>.Default;
++++++++for+(int+i+=+0;+i+<+Count;+i%2B%2B)
++++++++++++if+(comparer.Equals(this[i],+item))
++++++++++++++++return+i;
++++++++return+-1;
++++}
++++public+void+Add(T+item)
++++{
++++++++Insert(Count,+item);
++++}
++++public+void+Clear()
++++{+++//+Note:+the+class+would+be+allowed+to+override+the+trait+
++++++++//+with+a+better+implementation,+or+select+an+
++++++++//+implementation+from+a+different+trait.
++++++++for+(int+i+=+Count+-+1;+i+>=+0;+i--)
++++++++++++RemoveAt(i);
++++}
++++public+bool+Contains(T+item)
++++{
++++++++return+IndexOf(item)+!=+-1;
++++}
++++public+void+CopyTo(T[]+array,+int+arrayIndex)
++++{
++++++++foreach+(T+item+in+this)
++++++++++++array[arrayIndex%2B%2B]+=+item;
++++}
++++public+bool+IsReadOnly
++++{
++++++++get+{+return+false;+}
++++}
++++public+bool+Remove(T+item)
++++{
++++++++int+i+=+IndexOf(item);
++++++++if+(i+==+-1)
++++++++++++return+false;
++++++++RemoveAt(i);
++++++++return+true;
++++}
++++System.Collections.IEnumerator+
++++++++System.Collections.IEnumerable.GetEnumerator()
++++{
++++++++return+GetEnumerator();
++++}
++++IEnumerator<T>+GetEnumerator()
++++{
++++++++for+(int+i+=+0;+i+<+Count;+i%2B%2B)
++++++++++++yield+return+this[i];
++++}
}|code-block|syntax|javascript|360658|你可以像这样使用这个特征：|360659|class+MyList<T>+:+MyBaseClass,+DefaultListMethods<T>
{
++++public+void+Insert(int+index,+T+item)+{+...+}
++++public+void+RemoveAt(int+index)+++++++{+...+}
++++public+T+this[int+index]+{
++++++++get+{+...+}
++++++++set+{+...+}
++++}
++++public+int+Count+{
++++++++get+{+...+}
++++}
}|360660|当然，我在这里只是触及了皮毛。有关更完整的描述，请参阅论文Traits:+Composable+Units+of+Behavior。|offset|length|360661|Rust语言(来自Mozilla)以一种有趣的方式实现了特征:他们注意到特征类似于默认的接口实现，因此他们将接口和特征统一到一个功能中(称为特征)。特征和缺省接口实现(+Java现在有)之间的主要区别在于，特征可以包含私有或受保护的方法，而不像传统的接口方法必须是公共的。如果特征和接口不是统一到单个功能中，那么另一个区别是您可以引用接口，但不能引用特征；特征本身并不是一种类型。|360662|entityMap|0|LINK|mutability|MUTABLE|url|http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf^0|0|0|0|0|0|0|T|10|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|18|8|@]|9|@$Q|19|R|1A|1|1B]]|A|$]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

Multiple inheritance isn't supported by the CLR in any way I'm aware of, so I doubt it could be supported in an efficient way as it is in C++ (or Eiffel, which may do it better given that the language is specifically designed for MI).

A nice alternative to Multiple Inheritance is called Traits. It allows you to mix together various units of behavior into a single class. A compiler can support traits as a compile-time extension to the single-inheritance type system. You simply declare that class X includes traits A, B, and C, and the compiler puts the traits you ask for together to form the implementation of X.

For example, suppose you are trying to implement IList(of T). If you look at different implementations of IList(of T), they often share some of the exact same code. That's were traits come in. You just declare a trait with the common code in it and you can use that common code in any implementation of IList(of T) -- even if the implementation already has some other base class. Here's what the syntax might look like:

<pre><code>/// This trait declares default methods of IList&lt;T&gt;
public trait DefaultListMethods&lt;T&gt; : IList&lt;T&gt;
{
 // Methods without bodies must be implemented by another 
 // trait or by the class
 public void Insert(int index, T item);
 public void RemoveAt(int index);
 public T this[int index] { get; set; }
 public int Count { get; }

 public int IndexOf(T item)
 {
 EqualityComparer&lt;T&gt; comparer = EqualityComparer&lt;T&gt;.Default;
 for (int i = 0; i &lt; Count; i++)
 if (comparer.Equals(this[i], item))
 return i;
 return -1;
 }
 public void Add(T item)
 {
 Insert(Count, item);
 }
 public void Clear()
 { // Note: the class would be allowed to override the trait 
 // with a better implementation, or select an 
 // implementation from a different trait.
 for (int i = Count - 1; i &gt;= 0; i--)
 RemoveAt(i);
 }
 public bool Contains(T item)
 {
 return IndexOf(item) != -1;
 }
 public void CopyTo(T[] array, int arrayIndex)
 {
 foreach (T item in this)
 array[arrayIndex++] = item;
 }
 public bool IsReadOnly
 {
 get { return false; }
 }
 public bool Remove(T item)
 {
 int i = IndexOf(item);
 if (i == -1)
 return false;
 RemoveAt(i);
 return true;
 }
 System.Collections.IEnumerator 
 System.Collections.IEnumerable.GetEnumerator()
 {
 return GetEnumerator();
 }
 IEnumerator&lt;T&gt; GetEnumerator()
 {
 for (int i = 0; i &lt; Count; i++)
 yield return this[i];
 }
}
</code></pre>

And you use the trait like this:

<pre><code>class MyList&lt;T&gt; : MyBaseClass, DefaultListMethods&lt;T&gt;
{
 public void Insert(int index, T item) { ... }
 public void RemoveAt(int index) { ... }
 public T this[int index] {
 get { ... }
 set { ... }
 }
 public int Count {
 get { ... }
 }
}
</code></pre>

Of course, I'm just scratching the surface here. For a more complete description, see the paper <a href="http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf" rel="nofollow noreferrer">Traits: Composable Units of Behavior</a> (PDF).

The Rust language (from Mozilla) has implemented Traits in an interesting way: they noticed that traits are similar to default interface implementations, so they unified interfaces and traits into a single feature (which they call traits). The main difference between traits and default interface implementations (which Java now has) is that traits can contain private or protected methods, unlike traditional interface methods that must be public. If traits and interfaces are not unified into a single feature, then another difference is that you can have a reference to an interface, but you can't have a reference to a trait; a trait is not itself a type.

blocks|key|363975|text|处理多重继承的问题之一是接口继承和实现继承之间的区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|363976|C#已经通过使用纯接口实现了接口继承的干净实现(包括隐式或显式实现的选择)。|363977|如果查看C%2B%2B，对于在class声明中冒号后面指定的每个类，您获得的继承类型由访问修饰符(private、protected或public)确定。使用public继承，您可以获得多重继承的全部混乱--多个接口与多个实现混合在一起。使用private继承，您只需要实现。"class+Foo+:+private+Bar“对象永远不会传递给需要Bar的函数，因为Foo类实际上只有一个私有Bar字段和一个自动实现的+pattern。|offset|length|style|CODE|363978|纯多重实现继承(实际上就是自动委托)不会带来任何问题，如果在C#中实现的话会很棒。|363979|至于从类继承多个接口，有许多不同的可能设计来实现该功能。每种具有多重继承的语言都有自己的规则，即在多个基类中使用相同的名称调用方法时会发生什么。一些语言，如Common+Lisp+(特别是CLOS对象系统)和Python，具有元对象协议，您可以在其中指定基类优先级。|363980|这里有一种可能性：|363981|abstract+class+Gun
{+
++++public+void+Shoot(object+target)+{}+
++++public+void+Shoot()+{}

++++public+abstract+void+Reload();

++++public+void+Cock()+{+Console.Write("Gun+cocked.");+}
}

class+Camera
{+
++++public+void+Shoot(object+subject)+{}

++++public+virtual+void+Reload()+{}

++++public+virtual+void+Focus()+{}
}

//this+is+great+for+taking+pictures+of+targets!
class+PhotoPistol+:+Gun,+Camera
{+
++++public+override+void+Reload()+{+Console.Write("Gun+reloaded.");+}

++++public+override+void+Camera.Reload()+{+Console.Write("Camera+reloaded.");+}

++++public+override+void+Focus()+{}
}

var++++pp++++++=+new+PhotoPistol();
Gun++++gun+++++=+pp;
Camera+camera++=+pp;

pp.Shoot();++++++++++++++++++++//Gun.Shoot()
pp.Reload();+++++++++++++++++++//writes+"Gun+reloaded"
camera.Reload();+++++++++++++++//writes+"Camera+reloaded"
pp.Cock();+++++++++++++++++++++//writes+"Gun+cocked."
camera.Cock();+++++++++++++++++//error:+Camera.Cock()+not+found
((PhotoPistol)+camera).Cock();+//writes+"Gun+cocked."
camera.Shoot();++++++++++++++++//error:++Camera.Shoot()+not+found
((PhotoPistol)+camera).Shoot();//Gun.Shoot()
pp.Shoot(target);++++++++++++++//Gun.Shoot(target)
camera.Shoot(target);++++++++++//Camera.Shoot(target)|code-block|syntax|javascript|363982|在这种情况下，只有列出的第一个类的实现在冲突的情况下是隐式继承的。必须显式指定其他基类型的类才能获得它们的实现。为了使其更加可靠，编译器可以在冲突的情况下禁止隐式继承(冲突的方法总是需要强制转换)。|363983|此外，您现在还可以使用隐式转换操作符在C#中实现多重继承：|363984|public+class+PhotoPistol+:+Gun+/*+,Camera+*/
{
++++PhotoPistolCamera+camera;

++++public+PhotoPistol()+{
++++++++camera+=+new+PhotoPistolCamera();
++++}

++++public+void+Focus()+{+camera.Focus();+}

++++class+PhotoPistolCamera+:+Camera+
++++{+
++++++++public+override+Focus()+{+}
++++}

++++public+static+Camera+implicit+operator(PhotoPistol+p)+
++++{+
++++++++return+p.camera;+
++++}
}|363985|然而，它并不完美，因为is和as操作符以及System.Type.IsSubClassOf()都不支持它。|BOLD|363986|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Delegation_pattern^0|0|0|B|5|19|7|1H|9|1R|6|23|6|39|7|3R|N|4Q|3|4Z|3|5C|3|5P|8|0|0|0|0|0|0|0|0|0|B|2|E|2|B|2|E|2|L|Q|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1D|8|@$F|1E|G|1F|H|I]|$F|1G|G|1H|H|I]|$F|1I|G|1J|H|I]|$F|1K|G|1L|H|I]|$F|1M|G|1N|H|I]|$F|1O|G|1P|H|I]|$F|1Q|G|1R|H|I]|$F|1S|G|1T|H|I]|$F|1U|G|1V|H|I]|$F|1W|G|1X|H|I]]|9|@$F|1Y|G|1Z|1|20]]|A|$]]|$1|J|3|K|5|6|7|21|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|22|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|23|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|24|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|25|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|26|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|R|7|27|8|@]|9|@]|A|$S|T]]|$1|10|3|11|5|6|7|28|8|@$F|29|G|2A|H|12]|$F|2B|G|2C|H|12]|$F|2D|G|2E|H|I]|$F|2F|G|2G|H|I]|$F|2H|G|2I|H|I]]|9|@]|A|$]]|$1|13|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A]]]]

One of the issues with dealing with multiple inheritance is the distinction between interface inheritance and implementation inheritance. 

C# already has a clean implementation of interface inheritance (including choice of implicit or explicit implementations) by using pure interfaces.

If you look at C++, for each class you specify after the colon in the <code>class</code> declaration, the kind of inheritance you get is determined by the access modifier (<code>private</code>, <code>protected</code>, or <code>public</code>). With <code>public</code> inheritance, you get the full messiness of multiple inheritance&mdash;multiple interfaces are mixed with multiple implementations. With <code>private</code> inheritance, you just get implementation. An object of "<code>class Foo : private Bar</code>" can never get passed to a function that expects a <code>Bar</code> because it's as if the <code>Foo</code> class really just has a private <code>Bar</code> field and an automatically-implemented <a href="http://en.wikipedia.org/wiki/Delegation_pattern" rel="nofollow noreferrer" title="Wikipedia: Delegation Pattern">delegation pattern</a>. 

Pure multiple implementation inheritance (which is really just automatic delegation) doesn't present any problems and would be awesome to have in C#.

As for multiple interface inheritance from classes, there are many different possible designs for implementing the feature. Every language that has multiple inheritance has its own rules as to what happens when a method is called with the same name in multiple base classes. Some languages, like Common Lisp (particularly the CLOS object system), and Python, have a meta-object protocol where you can specify the base class precedence.

Here's one possibility:

<pre><code>abstract class Gun
{ 
 public void Shoot(object target) {} 
 public void Shoot() {}

 public abstract void Reload();

 public void Cock() { Console.Write("Gun cocked."); }
}

class Camera
{ 
 public void Shoot(object subject) {}

 public virtual void Reload() {}

 public virtual void Focus() {}
}

//this is great for taking pictures of targets!
class PhotoPistol : Gun, Camera
{ 
 public override void Reload() { Console.Write("Gun reloaded."); }

 public override void Camera.Reload() { Console.Write("Camera reloaded."); }

 public override void Focus() {}
}

var pp = new PhotoPistol();
Gun gun = pp;
Camera camera = pp;

pp.Shoot(); //Gun.Shoot()
pp.Reload(); //writes "Gun reloaded"
camera.Reload(); //writes "Camera reloaded"
pp.Cock(); //writes "Gun cocked."
camera.Cock(); //error: Camera.Cock() not found
((PhotoPistol) camera).Cock(); //writes "Gun cocked."
camera.Shoot(); //error: Camera.Shoot() not found
((PhotoPistol) camera).Shoot();//Gun.Shoot()
pp.Shoot(target); //Gun.Shoot(target)
camera.Shoot(target); //Camera.Shoot(target)
</code></pre>

In this case, only the first listed class's implementation is implicitly inherited in the case of a conflict. The class for other base types must be explicitly specified to get at their implementations. To make it more idiot-proof, the compiler can disallow implicit inheritance in the case of a conflict (conflicting methods would always require a cast). 

Also, you can implement multiple inheritance in C# today with implicit conversion operators:

<pre><code>public class PhotoPistol : Gun /* ,Camera */
{
 PhotoPistolCamera camera;

 public PhotoPistol() {
 camera = new PhotoPistolCamera();
 }

 public void Focus() { camera.Focus(); }

 class PhotoPistolCamera : Camera 
 { 
 public override Focus() { }
 }

 public static Camera implicit operator(PhotoPistol p) 
 { 
 return p.camera; 
 }
}
</code></pre>

It's not perfect, though, as it's not supported by the <code>is</code> and <code>as</code> operators, and <code>System.Type.IsSubClassOf()</code>.

blocks|key|359361|text|不，我们是从那里出来的。你现在确实需要它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|359362|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No, we came away from it. You do need it now.

blocks|key|360671|text|我更喜欢C%2B%2B。我使用过Java、C#等。随着我的程序在这样的面向对象环境中变得越来越复杂，我发现自己错过了多重继承。这是我的主观经验。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360672|它可以创造出令人惊叹的意大利面条，code...it可以创造出令人惊叹的优雅代码。|360673|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I prefer C++. I've used Java, C#, etc. As my programs get more sophisticated in such an OO environment, I find myself missing Multiple Inheritance. That's my subjective experience.

It can make for amazing spaghetti code...it can make for amazingly elegant code.

blocks|key|3150307|text|接口是多重继承。事实上，我认为Java/C#类型的接口是多重继承的“适当”实现。通过使用接口强制多继承，而不是允许从多个具体或抽象类继承，迫使开发人员使用组合/委托进行代码重用。继承永远不应该用于代码重用，并且C%2B%2B类型多重继承的缺失迫使开发人员提出更好的设计类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150308|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Interfaces are multiple inheritance. As a matter of fact, I would consider Java/C# type interfaces the "proper" implementation of multiple inheritance. Forcing multiple inheritance through the use of interfaces, rather then allowing inheritance from multiple concrete or abstract classes forces the developer to use composition/delegation for code reuse. Inheritance should never be used for code reuse and the absence of C++ type multiple inheritance forces developers to come up with better designed classes.

blocks|key|3363232|text|我很高兴C#没有多重继承，尽管它有时会很方便。相反，我希望看到的是提供接口方法的默认实现的能力。这就是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363233|interface+I
{
++++void+F();
++++void+G();
}


class+DefaultI+:+I
{
++++void+F()+{+...+}
++++void+G()+{+...+}
}

class+C+:+I+=+DefaultI
{
++++public+void+F()+{+...+}+//+implements+I.F
}|code-block|syntax|javascript|3363234|在这种情况下，((I)new+C()).F()将调用C的I.F()实现，而((I)new+C()).G()将调用DefaultI的I.G()实现。|offset|length|style|CODE|3363235|在将其添加到语言中之前，语言设计者必须解决许多问题，但这些问题都不是很难，并且结果将涵盖许多使多重继承变得可取的需求。|3363236|entityMap^0|0|0|7|G|Q|1|S|5|11|G|1K|8|1T|5|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]|$I|X|J|Y|K|L]|$I|Z|J|10|K|L]|$I|11|J|12|K|L]|$I|13|J|14|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|P|$]]

I'm happy that C# does not have Multiple Inheritance, even though it would sometimes be convenient. What I would like to see instead is the ability to provide a default implementation of an interface method. That is:

<pre><code>interface I
{
 void F();
 void G();
}


class DefaultI : I
{
 void F() { ... }
 void G() { ... }
}

class C : I = DefaultI
{
 public void F() { ... } // implements I.F
}
</code></pre>

In this case, <code>((I)new C()).F()</code> will call <code>C</code>'s implementation of <code>I.F()</code>, while <code>((I)new C()).G()</code> will call <code>DefaultI</code>'s implementation of <code>I.G()</code>.

There are a number of issues that the language designers would have to work out before this could be added to the language, but none that are very hard, and the result would cover many of the needs that make Multiple Inheritance desirable.

blocks|key|359379|text|DataFlex+4GL+v3%2B真正出色且(当时)新奇的功能之一(我知道，我知道，数据是什么？)它对mixin继承的支持-来自任何其他类的方法可以在类中重用；只要您的类提供了这些方法使用的属性，它就可以正常工作，并且没有“钻石问题”或其他多重继承“陷阱”需要担心。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|359380|我希望在C#中看到类似这样的东西，因为它可以简化某些类型的抽象和构造问题|359381|entityMap^0|1E|5|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|N|8|@]|D|@]|E|$]]]|I|$]]

one of the truly nice and (at the time) novel things about the DataFlex 4GL v3+ (I know, I know, Data what?) was its support for mixin inheritance - the methods from any other classes could be reused in your class; as long as your class provided the properties that these methods used, it worked just fine, and there was no "diamond problem" or other multiple-inheritance "gotchas" to worry about.

i would like to see something like this in C# as it would simplify certain kinds of abstraction and contruction issues

blocks|key|361437|text|实际上，我怀念多重继承的原因有一个……处置模式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361438|每次需要实现dispose模式时，我都会对自己说：“我希望我能从一个实现dispose模式的类中派生出一些虚拟重写。”我将相同的样板代码复制并粘贴到实现IDispose的每个类中，我讨厌这种做法。|361439|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I actually miss multiple inheritance for one specific reason... the dispose pattern. 

EVERY time that I need to implement the dispose pattern, I say to myself: "I wish I could just derive from a class that implements the dispose pattern with a few virtual overrides." I copy and paste the same boiler-plate code into every class that implements IDispose and I hate it.

blocks|key|3363319|text|我认为像C#这样的语言应该给程序员提供选择。仅仅因为它可能太复杂并不意味着它将会太复杂。编程语言应该为开发人员提供工具来构建程序员想要的任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363320|你选择使用开发人员已经编写的API，但你也没有。|3363321|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I believe languages like C# should give the programmer the option. Just because it maybe too complicated does not mean it will be too complicated. Programming languages should provide the developer with tools to build anything the programmer wants to. 

You choose to use those API's a developer already wrote, you dont have too.

blocks|key|3363362|text|是!是!而且是的！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363363|说真的，我的整个职业生涯都在开发GUI库，而MI+(多重继承)使得这比SI+(单一继承)容易得多。|3363364|首先，我在C%2B%2B中做了SmartWin%2B%2B+(MI大量使用)，然后我做了Gaia+Ajax，最后现在Ra-Ajax和我可以非常自信地说，MI在某些地方是规则的。其中一个地方就是GUI库...|offset|length|3363365|而那些声称MI“太复杂”之类的论点大多是由试图构建语言战争的人提出的，而且恰好属于“目前没有MI”的阵营……|3363366|就像函数式编程语言(如Lisp)被非函数式编程语言倡导者(由“非Lisper”)教导为“太复杂”一样……|3363367|人们害怕未知..。|3363368|我的规则！|3363369|entityMap|0|LINK|mutability|MUTABLE|url|http://smartwinlib.org/|1|http://ra-ajax.org/^0|0|0|B|A|0|1E|7|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@$F|12|G|13|1|14]|$F|15|G|16|1|17]]|A|$]]|$1|H|3|I|5|6|7|18|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|19|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1B|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]|X|$5|S|T|U|A|$V|Y]]]]

YES! YES! and YES!

Seriously, I've been developing GUI libraries my entire career, and MI (Multiple Inheritance) makes this FAR easier than SI (Single Inheritance)

First I did <a href="http://smartwinlib.org" rel="noreferrer">SmartWin++</a> in C++ (MI heavily used) then I did Gaia Ajax and finally now <a href="http://ra-ajax.org" rel="noreferrer">Ra-Ajax</a> and I can with extreme confident state that MI rules for some places. One of those places being GUI libraries...

And the arguments claiming that MI "is too complex" and such are mostly put there by people trying to construct language wars and happens to belong to the camp which "currently doesn't have MI"...

Just like functional programming languages (like Lisp) have been taught (by the "non-Lispers") as "too complex" by non-functional programming language advocates...

People are afraid of the unknown...

MI RULES!

blocks|key|3363371|text|给C#+implicits，你就不会错过多重继承，或者任何继承。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3363372|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.tmorris.net/implicits-for-the-fearless/^0|4|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Give C# <a href="http://blog.tmorris.net/implicits-for-the-fearless/" rel="nofollow noreferrer">implicits</a> and you will not miss multiple inheritance, or any inheritance for that matter.

blocks|key|361492|text|不，我没有。我使用所有其他面向对象的特性来开发我想要的东西。我使用接口和对象封装，我永远不会局限于我想做的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|361493|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No I do not. I use all other OO features to develop what I want. I use Interface and object encapsulation and I am never limited on what I want to do.

blocks|key|360703|text|我尽量不使用继承。我每次都能做到的越少。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360704|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I try not to use inheritance. The less I can everytime.

blocks|key|361495|text|您可以使用mixins来代替多重继承，这是一个更好的解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|361496|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/255553/is-it-possible-to-implement-mixins-in-c^0|5|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Instead of multiple inheritance, you can use <a href="https://stackoverflow.com/questions/255553/is-it-possible-to-implement-mixins-in-c">mixins</a> which is a better solution.

blocks|key|3150501|text|如果我们引入多重继承，那么我们将再次面临C%2B%2B的老菱形问题……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150502|然而，对于那些认为这是不可避免的，我们仍然可以通过组合的方式引入多重继承效果(在一个对象中组合多个对象，并公开将责任委托给组合对象并返回的公共方法)……|3150503|因此，为什么要麻烦拥有多重继承，并使您的代码容易受到不可避免的异常的影响……|3150504|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If we introduce Multiple Inheritance then we are again facing the old Diamond problem of C++...

However for those who think it's unavoidable we can still introduce multiple inheritance effects by means of composition (Compose multiple objects in an object and expose public methods which delegate responsibilities to composed object and return)... 

So why bother to have multiple inheritance and make your code vulnerable to unavoidable exceptions...

blocks|key|364154|text|我几乎不会错过C#中的多重继承。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364155|如果你使用多重继承来定义一个实际的领域模型，那么根据我的经验，你通常可以使用单一继承和一些好的设计模式来创建一个同样好的设计。|364156|我发现多重继承真正有价值的大多数地方都不是域本身，而是一些需要使用MI的技术/框架约束。使用ATL实现COM对象是一个很好的示例，它说明了如何使用多重继承来实现COM对象所需的所有必要接口，也是一种丑陋(与.NET相比)技术的优雅解决方案。从优雅的角度来看，它是一个C%2B%2B框架！|364157|不过，我现在有一种情况，我可以使用多重继承。我有一个类需要从其他域对象派生功能，但它也需要可供跨AppDomain调用访问。这意味着它必须从MarshalByRefObject继承。所以在这个特殊的例子中，我真的很想从MarshalByRefObject和我的特定域对象中派生。然而，这是不可能的，所以我的类必须实现与我的域对象相同的接口，并将调用转发到聚合实例。|364158|但正如我所说，这是一种技术/框架施加约束的情况，而不是域模型本身。|364159|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I almost don't miss multiple inheritance in C#.

If you are using multiple inhertance to define an actual domain model, then in my experience, you can often create an equally good design using single inheritance and some good design patterns.

Most of the places where I find multiple inheritance to be of real value are the places where it is not the domain itself, but some technology/framework constraint that requires you to use MI. Implementation of COM objects using ATL is a very good example of where you use multiple inheritance to implement all the necessary interfaces that you COM object needs, and an elegant solution to an ugly (compared to .NET) technology. Elegant from the point of view that it is a C++ framework!

I have a situation now though, where I could use multiple inheritance. I have one class that needs to derive features from some other domain object, but it also needs to be accessible for cross-AppDomain calls. This means that it MUST inherit from MarshalByRefObject. So in this particular case, I would really like to derive both from MarshalByRefObject and my specific domain object. That is not possible however, so my class has to implement the same interface as my domain object, and forward calls to an aggregated instance.

But this is, as I said, a case where the technology/framework places a constraint, and not the domain model itself.

blocks|key|3150597|text|我说不，直到钻石问题(使用类的多重继承不好的一个重要原因)得到充分解决，并且解决方案与使用接口一样好。简而言之，钻石问题基本上与类中数据、方法和事件的潜在模糊性有关，这是由于类的多重继承造成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150598|P/S你很少因为编程困难而回避你迫切需要的编程解决方案。“困难”不是没有多重继承的借口。多线程很难，但它在C#中是可用的。没有多重继承的一个很大原因是菱形问题(http://en.wikipedia.org/wiki/Diamond_problem)。一个笑脸的推理适用于你对更好的替代方案的评论(人们以不同的方式解决和思考，所以有时一个解决方案是一个糟糕的想法)，并且合适的选择已经存在(当ADO.NET成功并且mature...due到一个的优势时，为什么要创建LINQ？)|offset|length|3150599|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Diamond_problem^0|0|28|18|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

I say no until the Diamond Problem (a big reason why multiple inheritence with classes is bad) is solved adequately and if the solution is as good as using interfaces. In a nutshell, the Diamond Problem basically has to do with potential ambiguity in data, method and events in classes due to multiple inheritence via classes. 

P/S You "rarely" avoid a programming solution you badly need just because it is hard. "Difficulty" is no excuse for not having multiple inheritence. Multithreading is hard yet it is available in C#. A big for not having multiple inheritence is due to diamond problem (<a href="http://en.wikipedia.org/wiki/Diamond_problem" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Diamond_problem</a>). A smiliar reasoning apply to your comment about better alternatives (people solve and think in different ways so sometimes one solution is a bad idea) and suitable options already exist (why create LINQ when ADO.NET does the trick and is mature...due to the strength of one over the other.)

blocks|key|3363557|text|除非钻石问题得到解决，否则不会。你可以使用组合，直到这个问题没有解决为止。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3363558|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

No unless Diamond problem is solved. and you can use composition till this is not solved.

blocks|key|364169|text|如果接口可以实现，这将使事情变得更容易，代码更少。但是，它们是否会被误用而不是正确使用呢？我认为，在你看到如何正确地完成它之前，你不会错过它。我对多重继承是不安全的争论感到恼火。事实并非如此。但是几乎所有的语言实现都是。但是我们需要它吗？，我不知道。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364170|我更喜欢返回类型协方差，这可以很容易地添加(只需放宽规则，覆盖方法上的返回类型)，并且总是安全的。|364171|示例：|364172|class+shape+{}

class+circle+:+shape+{}

interface+part+{
++++shape+Form();
}

interface+wheel+:+part+{
++++circle+Form();
}|code-block|syntax|javascript|364173|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|O|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|P|8|@]|9|@]|A|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

It would make things easier, less code, if interfaces could have implementation. But could they be miss-used more than used properly? I think that until you see how it can be done properly, you wont miss it. I get annoyed with the arguments that multiple-inheritance is unsafe. It is not. But almost all language implementations are. But do we NEED it?, I don't know. 

I would prefer return type covariance, this can be added easily (just relax the rules, on the return type on over-ridden methods), and is always safe.

example:

<pre><code>class shape {}

class circle : shape {}

interface part {
 shape Form();
}

interface wheel : part {
 circle Form();
}
</code></pre>

I have come across numerous arguments against the inclusion of multiple inheritance in C#, some of which include (philosophical arguments aside):

<ul>
<li>Multiple inheritance is too complicated and often ambiguous</li>
<li>It is unnecessary because interfaces provide something similar</li>
<li>Composition is a good substitute where interfaces are inappropriate</li>
</ul>

I come from a C++ background and miss the power and elegance of multiple inheritance. Although it is not suited to all software designs there are situations where it is difficult to deny it's utility over interfaces, composition and similar OO techniques.

Is the exclusion of multiple inheritance saying that developers are not smart enough to use them wisely and are incapable of addressing the complexities when they arise?

I personally would welcome the introduction of multiple inheritance into C# (perhaps C##).

<hr>

Addendum: I would be interested to know from the responses who comes from a single (or procedural background) versus a multiple inheritance background. I have often found that developers who have no experience with multiple inheritance will often default to the multiple-inheritance-is-unnecessary argument simply because they do not have any experience with the paradigm.

Should C# have multiple inheritance?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我遇到过许多反对在C#中包含多重继承的争论，其中一些包括(哲学争论除外)：多重继承太复杂了，而且常常很模糊这是不必要的，因为接口提供了一些东西在接口不合适的情况下是很好的替代品我有C++背景，怀念多重继承的强大和优雅。尽管它并不适合所有的软件设计，但在某些情况下，很难否认它比接口、组合和类似的OO技术更有用。排除多重继...

问C#应该有多重继承吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#应该有多重继承吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#应该有多重继承吗？
EN