Question

我不一定会看到继承接口的接口带来的巨大好处。

考虑以下三个接口，第三个继承另外两个接口

interface IOne {
}

interface ITwo {
}

// interface inheritance
interface IAll : IOne, ITwo {
}

最好

class C : IOne, ITwo { ... }

或

class C : IAll { ... }

如果后者可能有益，那么为什么不创建IAll来拥有IOne和ITwo的所有方法而不继承它们呢？毕竟它是一个界面。

接口继承是否实用，不仅有用吗？

Answer 1

考虑接口“继承”的好方法是完全忘记它被称为“继承”。毕竟，“基础”界面显然没有为“派生”界面提供功能;它所贡献的只是承诺会有某些成员。

类派生关系通常意味着“is-a-kind-of”关系。 NullReferenceException是一种异常。界面派生关系并不意味着完全没有意义 - 说IEnumerable<T>是一种IDisposable是没有意义的。

相反，接口继承意味着“实现IEnumerable<T>的类型也需要实现IDisposable。也就是说，接口继承并不意味着”这是一种“，而是”每一个“实现这一点也需要实现“。

这会让它更引人注目吗？

Answer 2

做什么是语义正确的。不要只是为了在额外的界面中保存输入。

如果'IAll'是一个在你的程序中有意义的概念，那很好，使用它。如果它只是一种不键入'IFirst，ISecond'的方法，那就不要这样做。

Answer 3

可能有一些方法需要IAll参数 - 所以如果你满足实现整个IAll的要求，那么这样做很方便，而不是仅仅实现每个接口延伸！

通常，接口当然不是空的，因此在实现一个和/或另一个时需要特定的（可能很小的）成本（需要实现不同的，多个方法）。例如，如果IFirst有方法foo，而ISecond有方法bar，则将两者都扩展为IBoth是完全合理的不添加进一步需要的方法 - 它允许方法清楚地表明它需要一个具有两个方法的参数，foo 和 {{1} }。

如果世界上的每个界面都是空的，那么它们的使用（更不用扩展它们的空接口）将当然更可疑！ - ）

Answer 4

是的，接口继承是实用的。接口背后的想法是单个接口定义了一个松散的“契约”，描述了一组特定的功能。这样可以非常清晰地分离功能。

通常，需要实现多个接口的类通过单独列出每个接口来实现，例如：

class C : IOne, ITwo { ... }

如果您需要能够从多个接口聚合功能，那么您可能希望创建一个继承其他接口的接口（如IAll接口）。虽然你可以这样做，但你通常不需要（或不想）这样做。

Answer 5

我会采用第一种方法，对我来说更清楚。第二个似乎做作，IMO。

使用接口继承还是直接实现所有接口？

5 个答案: