C#缺乏多重继承是如何导致需要接口的？

Question

在C#编程语言中, Krzysztof Cwalina在一个注释中说:

我们明确决定不添加对多重继承的支持[...]缺少多重继承迫使我们添加接口的概念,这反过来又导致了框架演化,更深层次的继承层次结构等问题.问题.

接口是OO编程语言的核心概念.我不遵循"强迫我们添加接口的概念"的含义

Krzysztof是否意味着必须就接口的使用做出某些设计决策,否则将使用多重继承？或者,他interface是否因为缺乏多重继承而被引入C#？你能提供一个例子吗？

Answer 1

接口只是一个没有数据成员且只定义public abstract方法的基类.例如,这将是C++中的一个接口:

class IFrobbable {
    public:
    virtual void Frob() = 0;
}

因此,当MI可用作语言功能时,您可以通过简单地从它们派生来"实现"接口(再次,C++):

class Widget : public IFrobbable, public IBrappable {
    // ...
}

在一般情况下,多重继承会产生许多问题和问题,这些问题和问题不一定只有一个答案,甚至是一个很好的问题,对于你的"好"(可怕的钻石,任何人？)的特定定义.多接口实现完全回避了大多数这些问题,因为"继承"接口的概念是继承完整类的一个非常有限的特殊情况.

这就是"迫使我们添加接口的概念"的地方:在仅限于单继承的情况下,你不能做很多OO设计,例如,当代码重用实际上是一个时,无法重用代码的严重问题OO最常见的论点.您必须做更多的事情,下一步是添加多继承,但仅适用于满足接口约束的类.

所以,我解读Krzysztof的话

在一般情况下,多重继承是一个非常棘手的问题,在.NET开发的现实生活限制下,我们无法以令人满意的方式解决这个问题.但是,接口继承在OOP中更容易解决并且具有至关重要性,因此我们确实将其放入了.但是接口当然也有它们自己的一组问题,主要是关于BCL的结构.

Answer 2

来自Chris Brumme:

我们没有直接实现Multiple Implementation Inheritance的原因有很多.(如您所知,我们支持多接口继承).

我认为Krzysztof Cwalina在引用中所说的不是接口本身的概念,而是多接口继承作为多重继承的方法.

有几个原因我们没有提供多个实现继承的可编程,可验证,符合CLS的版本:

1. 不同的语言实际上对MI的工作方式有不同的期望.例如,如何解决冲突以及重复的基数是合并还是冗余.在我们在CLR中实现MI之前,我们必须对所有语言进行调查,找出常见概念,并决定如何以语言中立的方式表达它们.我们还必须决定MI是否属于CLS,这对于不想要这个概念的语言(例如VB.NET)意味着什么.当然,这是我们作为公共语言运行时所处的业务,但我们还没有为MI做这件事.

2. MI真正合适的地方实际上非常小.在许多情况下,多个接口继承可以完成工作.在其他情况下,您可以使用封装和委派.如果我们要添加一个稍微不同的构造,比如mixins,那实际上会更强大吗？

3. 多实现继承为实现注入了很多复杂性.这种复杂性会影响投射,布局,调度,现场访问,序列化,身份比较,可验证性,反射,泛型以及许多其他地方.

Answer 3

我认为您应该阅读Eric Lippert所说的话Interfaces。他的手脏了，所以我想他比其他人都知道。

有时有更坏的情况和最坏的情况。您必须选择较差的一种。

以下是链接帖子的副本：

它们只是为了确保（在接口中）所述功能在继承类中实现。

正确。这是足以证明该功能合理的好处。正如其他人所说，接口是实现某些方法，属性和事件的合同义务。静态类型语言的引人注目的好处是，编译器可以验证您的代码所依赖的合同是否确实得到满足。

也就是说，接口是表示合同义务的一种相当弱的方法。如果您想要一种更强大，更灵活的方式来表示合同义务，请查看Visual Studio的最新版本附带的“代码合同”功能。

C＃是一种很棒的语言，但是有时它给您的感觉是，Microsoft首先提出了问题（不允许多重继承），然后提供了解决方案，这是一个乏味的工作。

好吧，我很高兴你喜欢它。

所有复杂的软件设计都是相互权衡冲突的功能，并试图找到可以以小成本带来巨大收益的“最佳位置”的结果。我们通过痛苦的经验中学到，允许多继承以实现实现共享为目的的语言，其收益相对较小，成本较高。只允许在不共享实现细节的接口上进行多重继承，可以带来多重继承的许多好处，而无需花费很多成本。