寻找需要多接口继承（不是实现）的示例/案例

Question

C# 和 Java 都支持从多个父级继承的接口：

public interface IMyInterface : IInterface1, IInterface2

---

public interface MyInterface
extends Interface1, Interface2

我一直在 .NET Framework 和 JavaAPI 文档中查找使用多接口继承的示例。

在 JavaAPI 中，我找到了扩展超级接口和一个或多个“标记”接口的子接口示例（即它们没有定义的方法）。所以“标记”接口并没有真正在实现上强制执行任何东西。我可以看到这样做的好处，尤其是在引入注释之前。

在 .NET 中，我发现接口继承自多个已经相关的父级。例如IList 继承自ICollection 和IEnumerable 但ICollection 已经是IEnumerable 的后代。因此，在实现上强制执行 IEnumerable 已经通过单继承完成。

在任何一种情况下，多接口继承看起来要么是多余的，要么可以被更好的替代方案取代。

如果没有多重接口继承，有没有什么例子很难或不可能完成？

Answer 1

如果我理解您描述 .NET 接口继承链的方式，那么您就错了。这是一个容易犯的错误，因为文档使它看起来如此。 IList<T> 仅显式继承自 ICollection<T>；它不继承自ICollection<T>、IEnumerable<T> 和IEnumerable。以下是参考来源的实际定义：

public interface IList<T> : ICollection<T>

ICollection<T> 也是如此，它只继承自 IEnumerable<T>。在编译过程中，继承树在某种意义上被扁平化和去重，用于接口。因此，继承ICollection 的接口不仅仅继承了该接口，而后者又继承了IEnumerable。相反，接口将继承ICollection 和IEnumerable 本身。

视觉示例：

IMine : ICollection<T> != IMine : (ICollection<T>:(IEnumerable<T>:IEnumerable))

相反，它看起来像这样编译：

IMine: ICollection<T>, IEnumerable<T>, IEnumerable

这解释了为什么你会得出这样的结论。

---

关于多接口继承的真实世界示例，请查看IQueryable 和IOrderedQueryable 示例。这些接口的实际源码声明如下：

public interface IQueryable<out T> : IEnumerable<T>, IQueryable {}
public interface IOrderedQueryable<out T> : IQueryable<T>, IOrderedQueryable {}

IQueryable 需要有一个约定，指定您可以迭代每个元素，而且还需要能够与简单的IEnumerable 区分开来，因为它单独，不是所有IEnumerable 类型都可以用于IQueryProvider 和静态 Queryable 类。

---

另一个有趣的是在 System.Collections.Concurrent 命名空间中。

public interface IProducerConsumerCollection<T> : IEnumerable<T>, ICollection

这很有趣，因为它继承自 ICollection（非泛型）和 IEnumerable<T>，它们都继承自 IEnumerable。当然，这不是问题，但这是另一个很好的例子。如果IProducerConsumerCollection<T> 继承自ICollection<T> 而不是其非泛型对应物，我确信它不会显式继承自IEnumerable<T>。它具有ICollection 中定义的大小、（旧）枚举器和同步方法行为，以及IEnumerable<T> 中定义的通用枚举行为

有两个例子。我发现了更多，但我认为这些可能就足够了。

Answer 2

您应该从SOLID principles 中查看the Interface Segregation Principle (ISP)。基本上，您应该创建可以连接在一起的小型接口，而不是试图寻找一种组合它们的方法。为什么强制使用对某些类没有用的方法？这通常是多重继承的原因。

至于设计是否不可能，我会说不，因为您可以创建一个巨大的界面。但是，ISP 指出了这种方法的消极性，会使维护成为潜在的困难，但在初始设计中，我会说不，您不需要多重继承来完成实现。它可能看起来很乱就是了

Answer 3

如果您希望实现您的接口的所有对象都是 IDisposable 和 IComparable。

例如，如果您有一组资源，您可能希望根据它们的某些属性对它们进行排序或过滤（使用 IEquatable）。这意味着所有对象都必须实现这两个接口，您可以使用一个通用接口来强制实现这一点

IResource<T>: IDisposable, IComparable<T>, IEquatable<T>

Answer 4

在 Java 中：

Comparable 通常是您希望与主要类型分开的东西。

AbstractList 是 AbstractCollection 和 List 的子类型。

StringBuilder 既是CharSequence（读取接口）又是Appendable（写入接口）。我不太热衷于像那样将读取和写入合并在一起 - 不可变的值和告诉-不询问的接口。

显然有（主要是邪恶的）标记接口：Serializable、Cloneable 和 RandomAccess。

特别是 GUI 代码往往会将回调接口完全不必要地实现到一个 bug 类中，这通常会扩展一个它没有理由的类。