我通常在需要之前都不会实现。与抽象类相比，我更喜欢接口，因为这提供了更多的灵活性。如果在某些继承类中有共同的行为，我会将其上移并创建一个抽象基类。我不认为两者都有必要，因为它们本质上服务于相同的目的，而且两者都有一种糟糕的代码气味（imho），解决方案被过度设计了。

我有一个粗略的经验法则

功能：可能在所有部分都不同：界面。

数据和功能，部分基本相同，部分不同：抽象类。

数据和功能，实际工作，如果只进行了轻微的修改：普通（具体）类

数据和功能，没有计划的更改：带有最终修饰符的普通（具体）类。

数据，可能还有功能：只读：枚举成员。

这是非常粗略和准备好的，并且根本没有严格定义，但是有一个范围是从所有内容都要更改的接口到所有内容都像只读文件一样固定的enums。

通过def，接口提供了一个与其他代码通信的层。默认情况下，类的所有公共财产和方法都实现隐式接口。我们也可以将接口定义为一个角色，当任何类都需要扮演这个角色时，它必须实现它，根据实现它的类，给它不同的实现形式。oops的两个概念！！！

接口应较小。真的很小。如果你真的要分解你的对象，那么你的接口可能只包含一些非常具体的方法和财产。

抽象类是快捷方式。PetBase的所有衍生产品都有你可以编写一次代码并完成的东西吗？如果是的话，那么是抽象类的时候了。

抽象类也是有限的。虽然它们为您提供了生成子对象的绝佳捷径，但任何给定对象只能实现一个抽象类。很多时候，我发现这是抽象类的局限性，这也是我使用大量接口的原因。

抽象类可以包含多个接口。您的PetBase抽象类可以实现IPet（宠物有主人）和IDigestion（宠物吃，或者至少它们应该吃）。然而，PetBase可能不会实施IMammal，因为并非所有宠物都是哺乳动物，也并非所有哺乳动物都是宠物。您可以添加一个扩展PetBase的MammalPetBase并添加IMammal。FishBase可以有PetBase并添加IFish。IFish将使用ISwim和IUnderwaterBreaker作为接口。

是的，对于简单的示例来说，我的示例非常复杂，但这是接口和抽象类如何协同工作的一部分。

使用接口在不相关类的ACROSS家族中强制执行契约。例如，对于表示集合但包含完全不同数据的类，您可能有通用的访问方法，即一个类可能表示查询的结果集，而另一个类则可能表示库中的图像。此外，您可以实现多个接口，从而允许您混合（并表示）类的功能。

当类具有共同关系，因此具有相似的结构和行为特征时，使用继承，即汽车、摩托车、卡车和SUV都是可能包含多个车轮、最高速度的道路车辆

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

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