从概念上讲，接口用于正式和半正式地定义对象将提供的一组方法。形式上表示一组方法名称和签名，半形式上表示与这些方法相关的人类可读文档。

接口只是API的描述（毕竟，API代表应用程序编程接口），它们不能包含任何实现，也不可能使用或运行接口。它们只明确约定你应该如何与对象交互。

类提供了一个实现，它们可以声明它们实现了零个、一个或多个接口。如果要继承类，则惯例是在类名前面加上“Base”。

基类和抽象基类（ABC）之间有区别。ABC将接口和实现混合在一起。计算机编程之外的抽象意味着“摘要”，即“抽象==接口”。然后抽象基类可以描述接口，也可以描述要继承的空的、部分的或完整的实现。

关于何时使用接口、抽象基类还是仅使用类的意见将根据您正在开发的内容以及您正在使用的语言而大不相同。接口通常仅与静态类型语言（如Java或C#）相关，但动态类型语言也可以有接口和抽象基类。例如，在Python中，Class和对象之间的区别很明显，前者声明它实现了一个接口，后者是一个类的实例，据说提供了该接口。在动态语言中，两个都是同一类实例的对象可以声明它们提供完全不同的接口。在Python中，这仅适用于对象属性，而方法在类的所有对象之间共享状态。然而，在Ruby中，对象可以具有每实例方法，因此同一类的两个对象之间的接口可能会根据程序员的需要而变化（然而，Ruby没有任何明确的接口声明方式）。

在动态语言中，对象的接口通常是隐式假设的，可以通过内省对象并询问它提供了什么方法（在跳转之前查看），也可以通过简单地尝试在对象上使用所需的接口并在对象不提供该接口时捕捉异常（请求原谅比请求许可更容易）。这可能导致“误报”，即两个接口具有相同的方法名称，但语义不同。然而，权衡是代码更加灵活，因为您不需要预先过度指定以预测代码的所有可能用途。

通过def，接口提供了一个与其他代码通信的层。默认情况下，类的所有公共财产和方法都实现隐式接口。我们也可以将接口定义为一个角色，当任何类都需要扮演这个角色时，它必须实现它，根据实现它的类，给它不同的实现形式。oops的两个概念！！！

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

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

胡安，

我喜欢将接口视为一种描述类的方式。一个特定的犬类，比如约克郡梗，可能是母犬类的后代，但它也执行IFurry、IStubby和IYippieDog。所以类定义了类是什么，但接口告诉了我们关于它的事情。

这样做的好处是，例如，它允许我收集所有的IYippieDog，并将它们放入我的海洋收藏。因此，现在我可以跨越一组特定的对象，找到符合我所关注的标准的对象，而不必过于仔细地检查类。

我发现接口确实应该定义类的公共行为的子集。如果它为实现的所有类定义了所有公共行为，那么它通常不需要存在。他们没有告诉我任何有用的东西。

但这种想法与每个类都应该有一个接口的想法背道而驰，您应该编写接口代码。这很好，但最终会有很多一对一的类接口，这会让事情变得混乱。我知道这样做并不需要花费任何费用，现在你可以轻松地交换东西。然而，我发现我很少这样做。大多数时候，我只是在原地修改现有的类，如果该类的公共接口需要更改，我会遇到完全相同的问题，但我现在必须在两个地方更改它。

所以，如果你像我一样思考，你肯定会说《猫和狗》是IPettable的。这是一个符合两者的特征。

但另一个问题是，它们是否应该有相同的基类？问题是，它们是否需要被广泛地视为同一事物。当然，它们都是动物，但这是否符合我们将如何一起使用它们。

假设我想收集所有动物类并将它们放在我的方舟容器中。

或者它们需要是哺乳动物吗？也许我们需要某种跨动物挤奶工厂？

他们甚至需要联系在一起吗？仅仅知道它们都是IPettable就足够了吗？

当我真的只需要一个类时，我常常会感到想要派生出一个完整的类层次结构。我做这件事是为了期待有一天我可能会需要它，但通常我从来不会这样做。即使我做了，我通常也会发现我必须做很多事情来修复它。这是因为我创建的第一个类不是狗，我没有那么幸运，而是鸭嘴兽。现在，我的整个类层次结构都基于这个奇怪的案例，我有很多浪费的代码。

你可能还会发现，并不是所有的猫都是IPettable的（比如那个无毛的猫）。现在您可以将该接口移动到所有适合的派生类。你会发现，突然之间，猫不再是PettableBase的产物，这是一个小得多的变化。

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

Krzysztof Cwalina在第81页上说：

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

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

从概念上讲，接口用于正式和半正式地定义对象将提供的一组方法。形式上表示一组方法名称和签名，半形式上表示与这些方法相关的人类可读文档。

接口只是API的描述（毕竟，API代表应用程序编程接口），它们不能包含任何实现，也不可能使用或运行接口。它们只明确约定你应该如何与对象交互。

类提供了一个实现，它们可以声明它们实现了零个、一个或多个接口。如果要继承类，则惯例是在类名前面加上“Base”。

基类和抽象基类（ABC）之间有区别。ABC将接口和实现混合在一起。计算机编程之外的抽象意味着“摘要”，即“抽象==接口”。然后抽象基类可以描述接口，也可以描述要继承的空的、部分的或完整的实现。

关于何时使用接口、抽象基类还是仅使用类的意见将根据您正在开发的内容以及您正在使用的语言而大不相同。接口通常仅与静态类型语言（如Java或C#）相关，但动态类型语言也可以有接口和抽象基类。例如，在Python中，Class和对象之间的区别很明显，前者声明它实现了一个接口，后者是一个类的实例，据说提供了该接口。在动态语言中，两个都是同一类实例的对象可以声明它们提供完全不同的接口。在Python中，这仅适用于对象属性，而方法在类的所有对象之间共享状态。然而，在Ruby中，对象可以具有每实例方法，因此同一类的两个对象之间的接口可能会根据程序员的需要而变化（然而，Ruby没有任何明确的接口声明方式）。

在动态语言中，对象的接口通常是隐式假设的，可以通过内省对象并询问它提供了什么方法（在跳转之前查看），也可以通过简单地尝试在对象上使用所需的接口并在对象不提供该接口时捕捉异常（请求原谅比请求许可更容易）。这可能导致“误报”，即两个接口具有相同的方法名称，但语义不同。然而，权衡是代码更加灵活，因为您不需要预先过度指定以预测代码的所有可能用途。