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

另一个要记住的选项是使用“has-a”关系，也就是“以”或“组合的方式实现”。有时这是一种比使用“is-a”继承更干净、更灵活的结构方式。

从逻辑上说，狗和猫都“拥有”一只宠物可能不太合理，但它避免了常见的多重继承陷阱：

public class Pet
{
    void Bathe();
    void Train(Trick t);
}

public class Dog
{
    private Pet pet;

    public void Bathe() { pet.Bathe(); }
    public void Train(Trick t) { pet.Train(t); }
}

public class Cat
{
    private Pet pet;

    public void Bathe() { pet.Bathe(); }
    public void Train(Trick t) { pet.Train(t); }
}

是的，这个例子表明，在以这种方式做事时存在大量的代码重复和缺乏优雅。但我们也应该意识到，这有助于保持狗和猫与宠物类的分离（因为狗和猫不能访问宠物的私人成员），并为狗和猫从其他东西（可能是哺乳动物类）继承留下了空间。

当不需要私人访问并且您不需要使用通用的宠物参考/指针来参考狗和猫时，合成是最好的。接口为您提供了通用的引用功能，可以帮助减少代码的冗长，但当组织不好时，它们也会使事情变得模糊。当您需要私人成员访问时，继承是有用的，在使用它时，您将致力于将您的狗和猫类与您的宠物类高度耦合，这是一个巨大的成本。

在继承、组合和接口之间，没有一种方法总是正确的，考虑如何协调地使用这三种选项是有帮助的。在这三个选项中，继承通常是最不常用的选项。

下面是接口和基类的基本和简单定义：

基类=对象继承。接口=功能继承。

干杯

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

用你自己的判断，要聪明。不要总是照别人（像我）说的做。你会听到“更喜欢接口而不是抽象类”，但这取决于实际情况。这取决于班级。

在上面提到的情况下，我们有一个对象层次结构，接口是一个好主意。接口有助于处理这些对象的集合，在实现服务时也有助于使用层次结构中的任何对象。您只需定义一个用于处理层次结构中的对象的契约。

另一方面，当您实现一组共享公共功能的服务时，您可以将公共功能分离为一个完整的单独类，也可以将其移动到一个公共基类中，并使其抽象化，以便没有人可以实例化基类。

还要考虑如何随时间推移支持抽象。接口是固定的：您将一个接口作为任何类型都可以实现的一组功能的契约发布。基类可以随着时间的推移而扩展。这些扩展成为每个派生类的一部分。

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

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