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

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

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

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

把接口想象成一个契约。这是一种说法，“这些类应该遵循这些规则。”

所以在IAnimal的例子中，它是一种说，“我必须能够在实现IAnimal的类上调用Run, Walk等。”

为什么这个有用?您可能希望构建一个函数，该函数依赖于必须能够在对象上调用Run和Walk这一事实。你可以有以下内容:

public void RunThenWalk(Monkey m) {
    m.Run();
    m.Walk();
}

public void RunThenWalk(Dog d) {
    d.Run();
    d.Walk();
}

．.． 对所有你知道能跑能走的物体重复这一步骤。然而，在你的IAnimal接口中，你可以像下面这样定义函数:

public void RunThenWalk(IAnimal a) {
    a.Run();
    a.Walk();
}

通过根据接口编程，您实际上是信任类来实现接口的目的。所以在我们的例子中，想法是“我不在乎他们怎么跑和走，只要他们能跑和走。”只要他们履行协议，我的RunThenWalk就有效。它在不了解任何其他课程的情况下运行得很好。”

在这个相关的问题上也有很好的讨论。

当您希望能够对多个类型使用单个变量，但所有这些类型通过接口声明实现相同的方法时，Jimmy是正确的。然后你可以在接口类型变量上调用它们的main方法。

然而，使用接口还有第二个原因。当项目架构师和实现编码员是不同的人时，或者有几个实现编码员和一个项目经理。负责人可以编写一大堆接口，并查看系统的互操作，然后让开发人员用实现类填充接口。这是确保多人编写兼容类的最佳方法，而且他们可以并行地完成。

与任何为系统增加灵活性的编程技术一样，接口也增加了一定程度的复杂性。它们通常都很好，而且你可以在任何地方使用它(你可以为你的所有类创建一个接口)——但是这样做，你会创建一个更复杂的系统，更难维护。

像往常一样，这里有一个权衡:灵活性胜过可维护性。哪个更重要?没有答案——这取决于项目本身。但是请记住，每个软件都需要维护……

所以我的建议是:在真正需要接口之前不要使用它们。(使用Visual Studio，你可以在2秒内从现有的类中提取一个接口——所以不要着急。)

话虽如此，你什么时候需要创建一个接口呢?

当我重构一个突然需要处理两个或多个类似类的方法时，我就会这样做。然后创建一个接口，将该接口分配给两个(或多个)类似的类，并更改方法参数类型(将类类型替换为接口类型)。

它是有效的:o)

一个例外:当我模拟对象时，接口更容易使用。我经常为此创建接口。

PS:当我写“接口”时，我的意思是:“任何基类的接口”，包括纯接口类。请注意，抽象类通常比纯接口更好，因为您可以向它们添加逻辑。

此致,Sylvain。

假设你正在制作一款第一人称射击游戏。玩家有多种枪可供选择。

我们可以有一个接口Gun，它定义了函数shoot()。

我们需要不同的子类枪类，即霰弹枪狙击手等。

ShotGun implements Gun{
    public void shoot(){
       \\shotgun implementation of shoot.
    } 
}

Sniper implements Gun{
    public void shoot(){
       \\sniper implementation of shoot.
    } 
}

射击类

射手把所有的枪都装在他的盔甲里。让我们创建一个List来表示它。

List<Gun> listOfGuns = new ArrayList<Gun>();

射手在需要时使用switchGun()函数循环使用他的枪。

public void switchGun(){
    //code to cycle through the guns from the list of guns.
    currentGun = //the next gun in the list.
}

我们可以使用上面的函数设置当前的Gun，当调用fire()时，简单地调用shoot()函数。

public void fire(){
    currentGun.shoot();
}

shoot函数的行为将根据Gun接口的不同实现而有所不同。

结论

当一个类函数依赖于来自另一个类的函数时，创建一个接口，而另一个类根据实现的类的实例(对象)改变其行为。

例如，Shooter类的fire()函数期望枪械(Sniper, ShotGun)实现shoot()函数。 所以如果我们换枪开火。

shooter.switchGun();
shooter.fire();

我们已经改变了fire()函数的行为。

I like Jimmy's answer a lot, but I feel I need to add something to it. The key to the whole thing is the "able" in IProcessable . It indicates a capability (or property, but meaning "intrinsic quality", not in the sense of C# properties) of the object that implements the interface. IAnimal is probably not a good example for an interface, but IWalkable might be a good interface to have if your system has many things that can walk. You might have classes derived from Animal such as Dog, Cow, Fish, Snake. The first two would probably implement IWalkable, the latter two don't walk, so they wouldn't. Now you ask "why not just have another superclass, WalkingAnimal, that Dog and Cow derive from?". The answer is when you have something completely outside the inheritance tree that also can walk, such as a robot. Robot would implement IWalkable, but probably wouldn't derive from Animal. If you want a list of things that can walk, you type it as IWalkable and you can put all walking animals plus robots in the list.

现在，将IWalkable替换为IPersistable这样更像软件的东西，这样的类比就更接近你在实际程序中看到的情况了。