胡安，

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

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

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

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

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

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

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

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

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

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

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

当我第一次开始学习面向对象编程时，我犯了一个简单的、可能也是常见的错误，即使用继承来共享公共行为——即使这种行为对对象的本质来说并不重要。

为了进一步建立这个问题中经常使用的例子，有很多东西都是可拍的——女朋友、汽车、毛毯所以我可能有一个Petable类提供了这种常见的行为，以及从中继承的各种类。

然而，可拍不是这些物体的本质的一部分。还有很多更重要的概念对他们的天性至关重要——女朋友是人，汽车是陆地车辆，猫是哺乳动物。。。

行为应该首先被分配给接口（包括类的默认接口），并且只有当它们（a）对于作为更大类的子集的一大群类来说是公共的时，才应该被提升为基类——在相同的意义上，“猫”和“人”是“哺乳动物”的子集。

问题是，当你比我一开始更了解面向对象设计之后，你通常会自动完成这项工作，甚至不用考虑它。因此，“代码到接口，而不是抽象类”这句话的真实性变得如此明显，你很难相信任何人都会不厌其烦地说出它，并开始尝试将其他含义解读到其中。

我想补充的另一点是，如果一个类是纯抽象的-没有非抽象的、非继承的成员或方法暴露给子级、父级或客户端-那么为什么它是一个类？它可以被替换，在某些情况下被接口替换，在其他情况下被Null替换。

感谢Jon Limjap的回答，但我想为接口和抽象基类的概念添加一些解释

接口类型与抽象基类

改编自Pro C#5.0和.NET 4.5 Framework书籍。

接口类型似乎与抽象基类非常相似。回忆起当类被标记为抽象时，它可以定义任意数量的抽象成员来提供所有派生类型的多态接口。然而，即使类确实定义了一组抽象成员，还可以自由定义任意数量的构造函数、字段数据、非抽象成员（使用另一方面，接口只包含抽象成员定义。抽象父类建立的多态接口有一个主要限制因为只有派生类型支持抽象父级定义的成员。然而，在更大范围内软件系统，开发多个没有共同父级的类层次结构是非常常见的超出System.Object。假定抽象基类中的抽象成员仅适用于派生类型，我们无法在不同的层次结构中配置类型以支持相同的多态性界面例如，假设您定义了以下抽象类：

public abstract class CloneableType
{
// Only derived types can support this
// "polymorphic interface." Classes in other
// hierarchies have no access to this abstract
// member.
   public abstract object Clone();
}

给定此定义，只有扩展CloneableType的成员才能支持Clone（）方法如果创建一组不扩展此基类的新类，则无法获得多态界面。此外，您可能还记得C#不支持类的多重继承。因此，如果您想创建一辆小型货车，它是一辆汽车，并且是一种可克隆类型，那么您无法做到：

// Nope! Multiple inheritance is not possible in C#
// for classes.
public class MiniVan : Car, CloneableType
{
}

正如您所猜测的，接口类型起到了拯救作用。定义接口后，可以可以由任何类或结构、任何层次结构、任何命名空间或任何程序集中实现（用任何.NET编程语言编写）。正如您所看到的，接口是高度多态的。考虑System命名空间中定义的名为ICloneable的标准.NET接口。这接口定义了一个名为Clone（）的方法：

public interface ICloneable
{
object Clone();
}

接口和基类表示两种不同形式的关系。

继承（基类）表示“is-a”关系。例如，狗或猫是宠物。这种关系始终代表着班级的（单一）目的（结合“单一责任原则”）。

另一方面，接口表示类的其他特性。我将其称为“是”关系，如“Foo是一次性的”，因此C#中的IDisposable接口。

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

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

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

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