基类的继承者应该具有“is a”关系。接口表示“实现”关系。因此，只有在继承者将维护关系时才使用基类。

当我第一次开始学习面向对象编程时，我犯了一个简单的、可能也是常见的错误，即使用继承来共享公共行为——即使这种行为对对象的本质来说并不重要。

为了进一步建立这个问题中经常使用的例子，有很多东西都是可拍的——女朋友、汽车、毛毯所以我可能有一个Petable类提供了这种常见的行为，以及从中继承的各种类。

然而，可拍不是这些物体的本质的一部分。还有很多更重要的概念对他们的天性至关重要——女朋友是人，汽车是陆地车辆，猫是哺乳动物。。。

行为应该首先被分配给接口（包括类的默认接口），并且只有当它们（a）对于作为更大类的子集的一大群类来说是公共的时，才应该被提升为基类——在相同的意义上，“猫”和“人”是“哺乳动物”的子集。

问题是，当你比我一开始更了解面向对象设计之后，你通常会自动完成这项工作，甚至不用考虑它。因此，“代码到接口，而不是抽象类”这句话的真实性变得如此明显，你很难相信任何人都会不厌其烦地说出它，并开始尝试将其他含义解读到其中。

我想补充的另一点是，如果一个类是纯抽象的-没有非抽象的、非继承的成员或方法暴露给子级、父级或客户端-那么为什么它是一个类？它可以被替换，在某些情况下被接口替换，在其他情况下被Null替换。

接口有一个明显的优点，即对类来说有点“热交换”。将一个类从一个父类更改为另一个父级通常会导致大量工作，但通常可以删除和更改接口，而不会对实现类产生很大影响。这在您有几个“可能”希望类实现的窄行为集的情况下尤其有用。

这在我的领域尤其适用：游戏编程。基类可能会因继承对象“可能”需要的大量行为而变得臃肿。通过接口，可以轻松地向对象添加或删除不同的行为。例如，如果我为想要反映伤害的对象创建了“IDamageEffects”界面，那么我可以很容易地将其应用于各种游戏对象，并在以后很容易地改变主意。假设我设计了一个要用于“静态”装饰对象的初始类，我最初决定它们是不可破坏的。稍后，我可能会决定，如果它们可以爆炸，那会更有趣，所以我修改了类以实现“IDamageEffects”接口。这比切换基类或创建新的对象层次结构要容易得多。

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

这取决于您的要求。如果IPet足够简单，我更愿意实现它。否则，如果PetBase实现了大量您不想复制的功能，那么就试试看。

实现基类的缺点是需要重写（或新的）现有方法。这使它们成为虚拟方法，这意味着您必须小心如何使用对象实例。

最后，.NET的单一继承让我很头疼。一个天真的例子：假设你正在创建一个用户控件，那么你就继承了UserControl。但是，现在你被禁止继承PetBase。这迫使您重新组织，例如创建PetBase类成员。

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

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