我有一个粗略的经验法则

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

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

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

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

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

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

我有一个粗略的经验法则

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

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

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

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

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

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

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

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

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

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

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

Krzysztof Cwalina在第81页上说：

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

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

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

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