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

所以在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就有效。它在不了解任何其他课程的情况下运行得很好。”

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

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

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

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

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

作为一个。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就有效。它在不了解任何其他课程的情况下运行得很好。”

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

使用接口有很多目的。

Use in polymorphic behavior. Where you want to call specific methods of a child class with an inteface having a reference to the child class. Having a contract with classes to implement all of the methods where it is necessary, like most common use is with COM objects , where a wrapper class is generated on a DLL which inherits the interface; these methods are called behind the scenes, and you just need to implement them but with the same structure as defined in the COM DLL which you can only know through the interface that they expose. To reduce memory usage by loading specific methods in a class. Like if you have three business objects and they are implemented in a single class, you can use three interfaces.

例如IUser, IOrder, IOrderItem

public interface IUser()
{

void AddUser(string name ,string fname);

}

// Same for IOrder and IOrderItem
//


public class  BusinessLayer: IUser, IOrder, IOrderItem

{    
    public void AddUser(string name ,string fname)
    {
        // Do stuffs here.
    }

    // All methods from all interfaces must be implemented.

}

如果你只想添加一个用户，可以这样做:

IUser user = new (IUser)BusinessLayer();

// It will load  all methods into memory which are declared in the IUser interface.

user.AddUser();

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

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

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

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

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

它是有效的:o)

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

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

此致,Sylvain。