下面是一个矩形对象的接口:

interface IRectangular
{
    Int32 Width();
    Int32 Height();
}

它所要求的是实现访问对象宽度和高度的方法。

现在让我们定义一个方法，它可以作用于任何irectangle对象:

static class Utils
{
    public static Int32 Area(IRectangular rect)
    {
        return rect.Width() * rect.Height();
    }
}

这将返回任意矩形物体的面积。

让我们实现一个矩形的类SwimmingPool:

class SwimmingPool : IRectangular
{
    int width;
    int height;

    public SwimmingPool(int w, int h)
    { width = w; height = h; }

    public int Width() { return width; }
    public int Height() { return height; }
}

另一个类House也是矩形的:

class House : IRectangular
{
    int width;
    int height;

    public House(int w, int h)
    { width = w; height = h; }

    public int Width() { return width; }
    public int Height() { return height; }
}

鉴于此，你可以在房屋或游泳池上调用Area方法:

var house = new House(2, 3);

var pool = new SwimmingPool(3, 4);

Console.WriteLine(Utils.Area(house));
Console.WriteLine(Utils.Area(pool));

通过这种方式，您的类可以从任意数量的接口“继承”行为(静态方法)。

考虑接口的最简单方法是认识继承的意义。如果类CC继承了类C，这意味着:

类CC可以使用类C的任何public或protected成员，就像它们是自己的一样，因此只需要实现父类中不存在的东西。 对CC的引用可以传递或分配给期望对C的引用的例程或变量。

遗传的这两个功能在某种意义上是相互独立的;虽然继承同时应用这两个，但也可以应用第二个而不应用第一个。这很有用，因为允许一个对象从两个或多个不相关的类继承成员要比允许一种类型可以替代多种类型复杂得多。

接口有点像抽象基类，但有一个关键的区别:继承基类的对象不能继承任何其他类。相反，一个对象可以实现一个接口，而不影响它继承任何所需类或实现任何其他接口的能力。

One nice feature of this (underutilized in the .net framework, IMHO) is that they make it possible to indicate declaratively the things an object can do. Some objects, for example, will want data-source object from which they can retrieve things by index (as is possible with a List), but they won't need to store anything there. Other routines will need a data-depository object where they can store things not by index (as with Collection.Add), but they won't need to read anything back. Some data types will allow access by index, but won't allow writing; others will allow writing, but won't allow access by index. Some, of course, will allow both.

If ReadableByIndex and Appendable were unrelated base classes, it would be impossible to define a type which could be passed both to things expecting a ReadableByIndex and things expecting an Appendable. One could try to mitigate this by having ReadableByIndex or Appendable derive from the other; the derived class would have to make available public members for both purposes, but warn that some public members might not actually work. Some of Microsoft's classes and interfaces do that, but that's rather icky. A cleaner approach is to have interfaces for the different purposes, and then have objects implement interfaces for the things they can actually do. If one had an interface IReadableByIndex and another interface IAppendable, classes which could do one or the other could implement the appropriate interfaces for the things they can do.

你会得到界面，当你需要他们:)你可以研究例子，但你需要的是啊哈!效果才能真正得到他们。

现在您已经知道了接口是什么，只需编写没有接口的代码。您迟早会遇到一个问题，在这个问题中使用接口将是最自然的事情。

我很惊讶，没有多少文章包含一个最重要的接口原因:设计模式。这是使用契约的更大的前景，尽管它是机器代码的语法装饰(老实说，编译器可能会忽略它们)，但抽象和接口对于OOP、人类理解和复杂的系统架构来说是至关重要的。

让我们把披萨的比喻扩大到一顿完整的大餐。对于所有的食物类别，我们仍然有核心的Prepare()接口，但我们也有针对课程选择(前菜、主菜、甜点)的抽象声明，以及针对食物类型(咸的/甜的、素食的/非素食的、无麸质的等)的不同属性。

基于这些规范，我们可以实现抽象工厂模式来概念化整个过程，但是使用接口来确保只有基础是具体的。其他一切都可以变得灵活或鼓励多态，同时在实现iccourse接口的不同Course类之间保持封装。

如果我有更多的时间，我想画一个完整的例子，或者有人可以为我扩展它，但总的来说，c#接口将是设计这类系统的最佳工具。

考虑一下不控制或不拥有基类的情况。

以可视化控件为例，在。net for Winforms中，它们都继承自。net框架中完全定义的基类Control。

让我们假设您从事创建自定义控件的业务。你想要建立新的按钮，文本框，列表视图，网格，等等，你希望他们都有特定的功能独特的控件集。

例如，你可能想要一种通用的方法来处理主题，或者一种通用的方法来处理本地化。

在这种情况下，你不能“只创建一个基类”，因为如果你这样做，你必须重新实现所有与控件相关的东西。

相反，您将从按钮，TextBox, ListView, GridView等下降，并添加您的代码。

但这就产生了一个问题，你现在如何识别哪些控件是“你的”，你如何构建一些代码来表明“对于窗体上所有属于我的控件，将主题设置为X”。

输入接口。

接口是一种查看对象、确定对象是否遵守某种约定的方法。

您可以创建“YourButton”，从Button向下延伸，并添加对所需的所有接口的支持。

这将允许您编写如下代码:

foreach (Control ctrl in Controls)
{
    if (ctrl is IMyThemableControl)
        ((IMyThemableControl)ctrl).SetTheme(newTheme);
}

如果没有接口，这是不可能的，相反，你必须写这样的代码:

foreach (Control ctrl in Controls)
{
    if (ctrl is MyThemableButton)
        ((MyThemableButton)ctrl).SetTheme(newTheme);
    else if (ctrl is MyThemableTextBox)
        ((MyThemableTextBox)ctrl).SetTheme(newTheme);
    else if (ctrl is MyThemableGridView)
        ((MyThemableGridView)ctrl).SetTheme(newTheme);
    else ....
}

I share your sense that Interfaces are not necessary. Here is a quote from Cwalina pg 80 Framework Design Guidelines "I often here people saying that interfaces specify contracts. I believe this a dangerous myth. Interfaces by themselves do not specify much. ..." He and co-author Abrams managed 3 releases of .Net for Microsoft. He goes on to say that the 'contract' is "expressed" in an implementation of the class. IMHO watching this for decades, there were many people warning Microsoft that taking the engineering paradigm to the max in OLE/COM might seem good but its usefulness is more directly to hardware. Especially in a big way in the 80s and 90s getting interoperating standards codified. In our TCP/IP Internet world there is little appreciation of the hardware and software gymnastics we would jump through to get solutions 'wired up' between and among mainframes, minicomputers, and microprocessors of which PCs were just a small minority. So coding to interfaces and their protocols made computing work. And interfaces ruled. But what does solving making X.25 work with your application have in common with posting recipes for the holidays? I have been coding C++ and C# for many years and I never created one once.