当您成为库开发人员(为其他编码员编写代码的人)时，接口将变得很明显。我们中的大多数人都是从应用程序开发人员开始的，我们使用现有的api和编程库。

同样的，接口是一种契约，还没有人提到接口是一种使代码的某些部分稳定的好方法。当它是一个团队项目时(或者当您正在开发其他开发人员使用的代码时)，这尤其有用。所以，这里有一个具体的场景:

当您在团队中开发代码时，其他人可能会使用您编写的代码。当他们为你的(稳定的)接口编写代码时，他们会非常高兴，而当你可以自由地改变你的实现(隐藏在接口后面)而不破坏你团队的代码时，你也会非常高兴。它是信息隐藏的一种变体(接口是公开的，实现对客户端程序员隐藏)。阅读更多关于受保护的变种。

另请参阅有关接口编码的相关问题。

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.

当相同功能的实现不同时使用接口。

当你需要共享一个公共的具体实现时，使用一个抽象/基类。

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

我在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中的更改。(基类也有这个好处。)

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

一旦你需要为你的类强制一个行为，你应该定义一个接口。

动物的行为可能包括走、吃、跑等。因此，您将它们定义为接口。

另一个实际的例子是ActionListener(或Runnable)接口。您可以在需要跟踪特定事件时实现它们。因此，您需要在类(或子类)中提供actionPerformed(Event e)方法的实现。类似地，对于Runnable接口，提供公共void run()方法的实现。

此外，您可以让任意数量的类实现这些接口。

使用接口(在Java中)的另一个实例是实现c++中提供的多重继承。

当您希望定义对象可以显示的行为时，通常会使用接口。

在. net世界中，一个很好的例子是IDisposable接口，它用于任何使用必须手动释放的系统资源的Microsoft类。它要求实现它的类具有Dispose()方法。

Dispose()方法也被VB的using语言构造调用。NET和c#，只适用于IDisposables)

请记住，您可以通过使用诸如TypeOf…之类的构造来检查对象是否实现了特定的接口。Is (VB.NET)， Is (c#)， instanceof (Java)，等等…