在Submain.NET编码指南中很好地解释了接口上基类的情况：

基类与接口接口类型是部分值的描述，可能受许多对象类型支持。使用基类而不是接口只要可能。从版本控制透视，类更灵活而不是接口。有了课，你可以发布版本1.0，然后发布版本2.0向类中添加新方法。只要该方法不是抽象的，任何现有派生类都将继续功能不变。因为接口不支持实现继承应用于类的模式不适用于接口。添加方法与接口等效向基中添加抽象方法班实现接口将中断，因为类不实现新方法。接口适用于以下情况：几个不相关的类希望支持该协议。这些类已经建立了基类（对于实例一些是用户界面（UI）控件，一些是XMLWeb服务）。聚合不合适或不可行。在所有其他情况，类继承是更好的模型。

现代风格是定义IPet和PetBase。

该接口的优点是其他代码可以使用它，而与其他可执行代码没有任何联系。完全“干净”。界面也可以混合。

但是基类对于简单的实现和通用实用程序很有用。因此，还提供一个抽象基类，以节省时间和代码。

以前关于将抽象类用于公共实现的评论无疑是正确的。我还没有看到提到的一个好处是，使用接口可以更容易地实现用于单元测试的模拟对象。如Jason Cohen所描述的那样定义IPet和PetBase，使您能够轻松模拟不同的数据条件，而无需物理数据库的开销（直到您决定是时候测试真实数据为止）。

这是非常特定于.NET的，但《框架设计指南》一书认为，一般来说，类在不断发展的框架中提供了更多的灵活性。一旦一个接口交付，您就没有机会在不破坏使用该接口的代码的情况下更改它。然而，对于类，你可以修改它，而不是破坏链接到它的代码。只要你做了正确的修改，包括添加新的功能，你就可以扩展和发展你的代码。

Krzysztof Cwalina在第81页上说：

在.NETFramework的三个版本中，我已经与我们团队中的许多开发人员讨论了这一指南。他们中的许多人，包括那些最初不同意该指南的人，都表示他们后悔将一些API作为接口提供。我甚至没有听说过一个案例，其中有人后悔他们运送了一节课。

也就是说，当然有接口的地方。作为一般准则，始终提供接口的抽象基类实现，作为实现接口的方法的示例。在最佳情况下，基类将节省大量工作。

如果除了您的类型成员之外，其他开发人员确实没有任何理由希望使用自己的基类，并且您预见到版本控制问题，那么您应该使用基类（请参见http://haacked.com/archive/2008/02/21/versioning-issues-with-abstract-base-classes-and-interfaces.aspx).

如果继承开发人员有任何理由使用自己的基类来实现类型的接口，并且您没有看到接口发生变化，那么就使用接口。在这种情况下，为了方便起见，您仍然可以加入实现接口的默认基类。

还请记住，不要在OO中被卷走（请参见博客），并始终基于所需的行为来建模对象，如果您设计的应用程序中唯一需要的行为是动物的通用名称和物种，那么您只需要一个类animal，而不是世界上每种可能的动物都需要数百万个类。