让我们以Dog和Cat类为例，使用C#进行演示：

狗和猫都是动物，特别是四足哺乳动物（动物太普通了）。让我们假设您有一个抽象类Mammal，用于这两个类：

public abstract class Mammal

此基类可能具有默认方法，例如：

喂养朋友

所有这些都是在两个物种之间或多或少具有相同实现的行为。要定义此项，您需要：

public class Dog : Mammal
public class Cat : Mammal

现在让我们假设还有其他哺乳动物，我们通常会在动物园里看到：

public class Giraffe : Mammal
public class Rhinoceros : Mammal
public class Hippopotamus : Mammal

这仍然有效，因为Feed（）和Mate（）功能的核心仍然相同。

然而，长颈鹿、犀牛和河马并不是你可以用来做宠物的动物。这就是界面将有用的地方：

public interface IPettable
{
    IList<Trick> Tricks{get; set;}
    void Bathe();
    void Train(Trick t);
}

上述合同的执行在猫和狗之间是不同的；将它们的实现放在抽象类中继承将是一个坏主意。

狗和猫的定义现在应该如下：

public class Dog : Mammal, IPettable
public class Cat : Mammal, IPettable

理论上，您可以从更高的基类重写它们，但本质上，接口允许您只将所需的内容添加到类中，而不需要继承。

因此，由于您通常只能从一个抽象类继承（在大多数静态类型的OO语言中，即……例外包括C++），但能够实现多个接口，因此它允许您严格按照需要构造对象。

现代风格是定义IPet和PetBase。

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

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

继承还有其他优点，例如变量能够保存父类或继承类的对象（无需将其声明为泛型，如“object”）。

例如，在.NET WinForms中，大多数UI组件都是从System.Windows.Forms.Control派生的，因此声明为的变量可以“容纳”几乎所有UI元素，无论是按钮、ListView还是其他元素。当然，现在你不能访问项目的所有财产或方法，但你可以拥有所有基本的东西——这可能很有用。

除了那些提到IPet/PetBase实现的注释之外，在某些情况下，提供访问器帮助器类可能非常有价值。

IPet/PetBase风格假设您有多个实现，从而增加了PetBase的价值，因为它简化了实现。然而，如果您有多个客户端，则提供一个类帮助来帮助使用接口，可以通过使接口更容易使用来降低成本。

通常，您应该喜欢接口而不是抽象类。使用抽象类的一个原因是，如果在具体类之间有共同的实现。当然，您仍然应该声明一个接口（IPet），并让一个抽象类（PetBase）实现该接口。使用小的、不同的接口，您可以使用多个来进一步提高灵活性。接口允许最大限度的灵活性和跨边界类型的可移植性。当跨越边界传递引用时，始终传递接口而不是具体类型。这允许接收端确定具体实施，并提供最大的灵活性。当以TDD/BDD方式编程时，这是绝对正确的。

“四人帮”在他们的书中说：“因为继承将子类暴露于其父类实现的细节，所以人们常说‘继承破坏了封装’。”。我相信这是真的。

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

Krzysztof Cwalina在第81页上说：

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

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