我建议尽可能使用组合而不是继承。使用接口，但对基本实现使用成员对象。这样，您可以定义一个工厂，该工厂构造对象以某种方式运行。如果要更改行为，则创建一个新的工厂方法（或抽象工厂），以创建不同类型的子对象。

在某些情况下，如果所有可变行为都在帮助对象中定义，那么您可能会发现主对象根本不需要接口。

因此，您可能会得到一个带有IFurBehavior参数的宠物，而不是IPet或PetBase。IFurBehavior参数由PetFactory的CreateDog（）方法设置。shed（）方法调用的就是这个参数。

如果你这样做，你会发现你的代码更加灵活，你的大多数简单对象都处理非常基本的系统范围行为。

即使在多种继承语言中，我也推荐这种模式。

接口

大多数语言允许您实现多个接口修改接口是一项突破性的更改。所有实现都需要重新编译/修改。所有成员都是公共的。实现必须实现所有成员。接口有助于解耦。您可以使用模拟框架模拟接口后面的任何内容接口通常表示一种行为接口实现彼此分离/隔离

基类

允许您添加一些通过派生免费获得的默认实现（从C#8.0通过接口可以获得默认实现）除了C++，您只能从一个类派生。即使可以从多个类中选择，这通常也是一个坏主意。更改基类相对容易。派生不需要做任何特殊的事情基类可以声明可由派生访问的受保护函数和公共函数抽象基类不能像接口那样容易被模仿基类通常表示类型层次结构（IS A）类派生可能会依赖于一些基本行为（具有复杂的父实现知识）。如果你对一个人的基本实现进行更改并打破其他人，事情可能会很混乱。

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

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

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

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

Krzysztof Cwalina在第81页上说：

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

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

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

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

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