我偶尔也会使用接口，下面是我最新的用法(名称已经概括了):

我在WinForm上有一堆需要将数据保存到业务对象的自定义控件。一种方法是分别调用每个控件:

myBusinessObject.Save(controlA.Data);
myBusinessObject.Save(controlB.Data);
myBusinessObject.Save(controlC.Data);

这个实现的问题是，每当我添加一个控件，我必须进入我的“保存数据”方法，并添加新的控件。

我改变了我的控件来实现一个ISaveable接口，它有一个方法SaveToBusinessObject(…)，所以现在我的“保存数据”方法只是通过控件迭代，如果它发现一个是ISaveable，它调用SaveToBusinessObject。所以现在当需要一个新的控件时，所有人要做的就是在该对象中实现ISaveable(并且永远不要触及其他类)。

foreach(Control c in Controls)
{
  ISaveable s = c as ISaveable;

  if( s != null )
      s.SaveToBusinessObject(myBusinessObject);
}

接口通常未被意识到的好处是本地化修改。定义之后，您很少会更改应用程序的整体流程，但通常会在细节级别上进行更改。当您将细节保存在特定对象中时，ProcessA中的更改将不会影响ProcessB中的更改。(基类也有这个好处。)

编辑:另一个好处是行动的专一性。就像在我的例子中，我所要做的就是保存数据;我不关心它是什么类型的控件，或者它是否可以做任何其他事情——我只想知道我是否可以保存控件中的数据。它使我的保存代码非常清晰——没有检查它是否为文本、数字、布尔值或任何东西，因为自定义控件处理所有这些。

一个代码示例(结合了Andrew的代码和我的额外的关于“接口的目的是什么”的代码)，也说明了为什么在不支持多重继承的语言(c#和java)上接口而不是抽象类:

interface ILogger
{
    void Log();
}
class FileLogger : ILogger
{
    public void Log() { }
}
class DataBaseLogger : ILogger
{
    public void Log() { }
}
public class MySpecialLogger : SpecialLoggerBase, ILogger
{
    public void Log() { }
}

注意，FileLogger和DataBaseLogger不需要接口(可以是Logger的抽象基类)。但是考虑到您需要使用第三方记录器，它迫使您使用基类(假设它公开了您需要使用的受保护的方法)。由于语言不支持多重继承，您将无法使用抽象基类方法。

底线是:尽可能使用接口来获得代码的额外灵活性。您的实现不那么受约束，因此它能更好地适应变化。

最简单的例子就是支付处理器。(Paypal, PDS等)。

假设您创建了一个具有ProcessACH和ProcessCreditCard方法的接口IPaymentProcessor。

现在可以实现一个具体的Paypal实现。让这些方法调用PayPal特定的函数。

如果你决定以后需要换到另一个提供商，你可以这样做。只需为新提供程序创建另一个具体实现。由于您所绑定的只是您的接口(契约)，因此您可以在不更改使用它的代码的情况下切换应用程序使用的接口。

In my experience the driving force to create interfaces didn't occur until I start doing unit testing with a mocking framework. It became abundantly clear that using interfaces was going to make mocking much easier (since the framework depended on the methods being virtual). Once I started I saw the value of abstracting away the interface to my class from the implementation. Even if I don't create an actual interface, I try now to make my methods virtual (providing an implicit interface that can be overridden).

我发现还有许多其他原因可以加强重构到接口的良好实践，但是单元测试/模拟的事情提供了最初的“顿悟时刻”的实践经验。

EDIT: To clarify, with unit testing and mocking I always have two implementations -- the real, concrete implementation and an alternate mock implementation used in testing. Once you have two implementations, the value of the interface becomes obvious -- deal with it in terms of the interface so you can replace the implementation at any time. In this case I'm replacing it with a mock interface. I know that I can do this without an actual interface if my class is constructed properly, but using an actual interface reinforces this and makes it cleaner (clearer to the reader). Without this impetus, I don't think I would have appreciated the value of interfaces since most of my classes only, ever have a single concrete implementation.

As several people have probably already answered, interfaces can be used to enforce certain behaviors between classes that will not implement those behaviors the same way. So by implementing an interface you are saying that your class has the behavior of the interface. The IAnimal interface would not be a typical interface because Dog, Cat, Bird, etc. classes are types of animals, and should probably extend it, which is a case of inheritance. Instead, an interface would be more like animal behavior in this case, such as IRunnable, IFlyable, ITrainable, etc.

接口有很多好处，其中一个关键就是可插拔性。例如，声明一个具有List参数的方法将允许传入实现List接口的任何东西，允许开发人员在以后删除和插入不同的列表，而不必重写大量代码。

您可能永远不会使用接口，但如果您正在从头开始设计一个项目，特别是某种类型的框架，您可能会想要熟悉它们。

我建议大家阅读Coad、Mayfield和Kern撰写的《Java设计》中关于接口的章节。它们比一般的介绍性文本解释得好一点。如果你不使用Java，你可以只阅读本章的开头，主要是一些概念。

作为一个。net开发人员，你完全有可能一辈子都不编写自己的接口。毕竟，没有它们，我们也活了几十年，我们的语言仍然是图灵完备的。

我不能告诉你为什么你需要接口，但我可以给你一个我们在当前项目中使用它们的列表:

在我们的插件模型中，我们通过接口加载插件，并将该接口提供给插件编写者以使其遵循。 在我们的机间消息传递系统中，消息类都实现了一个特定的接口，并使用该接口“解包装”。 我们的配置管理系统定义了一个用于设置和检索配置设置的接口。 我们使用一个接口来避免讨厌的循环引用问题。(如果没有必要，就不要这样做。)

我想如果有一个规则，那就是当你想在一个is-a关系中对几个类进行分组，但你不想在基类中提供任何实现时使用接口。