我最近询问了这个question是否应该实现接口或抽象类。斯科特给出了答案，建议我同时使用两者，但我仍然不确定为什么我会这样做。从长远来看是否有好处？这样做有什么好处？
我认为以下是一些好处：
这是另一个问题。如果我实现了一个接口，那么接口是否只包含所有子类都可以做的方法？如果我需要额外的逻辑，我会创建一个具有更具体实现的具体类或抽象类。
答案 0 :(得分：6)
这种方法为您提供了两全其美的优势 - 接口的灵活性和基类的有用选项。
仅要求消费者实现你的接口，你不会强迫他们失去对他们的类开放的唯一继承槽（C＃不允许多重继承）。
但是通过另外提供一个抽象基类，你可以给它们一个“支持”，也许是通过实现一些辅助功能，这可能是你的界面的大多数实现的常见要求 - 例如，这可以使用模板方法模式来实现。
.NET Framework本身有几个示例，它们都是公开的接口和基类。例如System.ComponentModel.IComponent和System.ComponentModel.Component
这是另一个问题。如果我实现一个接口，应该 interface只包含所有子类都可以执行的方法吗？
是。你基本上是在描述Interface Segregation Principle。
答案 1 :(得分：2)
界面将定义合同。任何实施者（直接或通过抽象实施者）都符合本合同。
抽象类意味着您可以跨具体实现重用实现的某些部分 - 您可以拥有多个抽象类，实现方式不同。
答案 2 :(得分：1)
我在这里假设C＃，因为另一个问题有一个C＃标签
显而易见的好处是，将来你有另一个类，它已经从基类继承，并且你想将它传递给接受它的方法。 。 。
你不能把第一个基类放在那里，因为C＃并不是所有的多重继承，所以你永远不能传递那个子类不同的类的对象。
然而，您可以在其中放置接口，因为新对象始终可以实现接口，即使它在逻辑上应该从基类派生。
两者都意味着基类可以实现适合你的接口，因为你可以在其中放置通用逻辑，你不需要重复自己，或者在“helper”类中有一堆静态方法。
此外，如果你有其他想要使用的类，它们不必继承基类，那么就可以实现接口。
希望这是有道理的：）