让抽象类实现接口的好处？答案

【问题标题】：Benefit of having an abstract class implement an interface?让抽象类实现接口的好处？
【发布时间】：2011-11-27 19:45:02
【问题描述】：

我最近问过这个question 我是否应该实现接口或抽象类。 Scottm 给出的答案建议我同时使用两者，但我仍然不确定我为什么要这样做。从长远来看有好处吗？这样做有什么好处？

以下是我认为的一些好处：

这是另一个问题。如果我实现一个接口，该接口应该只包含所有子类都可以做的方法吗？如果我需要额外的逻辑，我会创建一个具有更具体实现的具体类或抽象类。

【问题讨论】：

我想知道.net 5.0 是否可以通过允许接口与静态基类配对来缓解限制，并允许接口使用静态类成员声明方法和属性的默认实现。我认为这样做不会有任何重大的技术困难（每个接口成员都会获得一个 vtable 插槽，但有些会指向静态方法），它既可以使接口可扩展，又可以消除对“合作伙伴”的需求提供诸如 Enumerable.Empty 之类的静态类（与 IEnumerable.Empty 相对）

【解决方案1】：

这种方法为您提供了两全其美的优势 - 接口的灵活性和有用的基类选项。

通过要求消费者实现您的接口，您不会强迫他们失去对其类开放的唯一继承槽（C# 不允许多重继承）。

但是通过另外提供一个抽象基类，你可以给他们一个“腿”，也许通过实现一些可能是大多数接口实现的共同要求的辅助功能 -例如，这可以使用模板方法模式来实现。

在 .NET Framework 本身中有几个公开接口和基类的示例。例如System.ComponentModel.IComponent 和System.ComponentModel.Component

这是另一个问题。如果我实现一个接口，应该接口只包含所有子类都可以做的方法？

是的。您实际上是在描述Interface Segregation Principle。

【讨论】：

【解决方案2】：

接口将定义合同。任何实现者（直接或通过抽象实现者）都将遵守本合同。

抽象类意味着您可以跨具体实现重用实现的部分内容 - 您可以拥有多个抽象类，以不同的方式实现。

【讨论】：

【解决方案3】：

我在这里假设 C#，因为另一个问题有一个 C# 标签

明显的好处是，将来你有另一个类，它已经从一个基类继承，你想把它传递给一个接受 . . .

你不能把第一个基类放在那里，因为C#并不都是多重继承，所以你永远不能在里面传递一个不同类的子类的对象。

但是，您可以将 interface 放在那里，因为新对象总是可以实现接口，即使它在逻辑上应该从基类派生。

两者都意味着基类可以实现接口，现在适合你，因为你可以把通用逻辑放在那里，你不需要重复自己，或者在“帮助”类中有一堆静态方法。

另外如果你以后有其他的类要使用，也不必继承基类，直接实现接口即可。

希望这是有道理的:)

【讨论】：