短篇故事:一个邮递员被要求挨家挨户地接收写有地址的信封(信件、文件、支票、礼品卡、申请书、情书)。

假设没有封面，让邮递员挨家挨户地接收所有的东西，然后交给其他人，邮递员会感到困惑。

所以最好用封面(在我们的故事中是接口)包装它，然后他就会很好地完成他的工作。

现在邮差的工作只是收和送封皮(他不关心封皮里面有什么)。

创建一个接口类型，而不是实际类型，而是使用实际类型实现它。

创建一个接口意味着你的组件可以很容易地适应其余的代码

我给你们举个例子。

你有一个plane界面，如下所示。

interface Airplane{
    parkPlane();
    servicePlane();
}

假设在平面的Controller类中有这样的方法

parkPlane(Airplane plane)

and

servicePlane(Airplane plane)

在您的程序中实现。它不会破坏你的代码。 我的意思是，只要它接受参数plane，它就不需要改变。

因为它将接受任何飞机，不管实际类型，飞行员，高空飞行，战斗机等。

同样，在集合中:

列表> <飞机飞机;//会占用你所有的飞机。

下面的例子将帮助您理解。

---

你有一架战斗机来执行它，所以

public class Fighter implements Airplane {

    public void  parkPlane(){
        // Specific implementations for fighter plane to park
    }
    public void  servicePlane(){
        // Specific implementatoins for fighter plane to service.
    }
}

HighFlyer和其他类也是如此:

public class HighFlyer implements Airplane {

    public void  parkPlane(){
        // Specific implementations for HighFlyer plane to park
    }

    public void  servicePlane(){
        // specific implementatoins for HighFlyer plane to service.
    }
}

现在假设你的控制器类多次使用AirPlane，

假设你的控制器类是ControlPlane，如下所示，

public Class ControlPlane{ 
 AirPlane plane;
 // so much method with AirPlane reference are used here...
}

神奇的是，你可以在不改变ControlPlane类代码的情况下，尽可能多地创建新的AirPlane类型实例。

你可以添加一个实例…

JumboJetPlane // implementing AirPlane interface.
AirBus        // implementing AirPlane interface.

您也可以删除以前创建的类型的实例。

面向接口编程非常棒，它促进了松耦合。正如@lassevk提到的，控制反转是一个很好的应用。

此外，研究SOLID原则。这是一个系列视频

它通过硬编码(强耦合示例)，然后查看接口，最后进展到IoC/DI工具(NInject)。

如果我正在编写一个新类Swimmer来添加swim()功能，并且需要使用类的对象说Dog，并且这个Dog类实现了声明swim()的接口Animal。

在层次的顶端(动物)，它是非常抽象的，而在底层(狗)，它是非常具体的。我认为“面向接口编程”的方式是，当我编写Swimmer类时，我想针对层次结构最高的接口编写代码，在本例中是Animal对象。接口没有实现细节，因此使代码松耦合。

实现细节可以随着时间的推移而改变，但是，它不会影响剩余的代码，因为您所与之交互的是接口而不是实现。你不关心实现是什么样的……您所知道的是，将会有一个实现该接口的类。

这里有一些关于这个问题的很好的答案，涉及到各种关于接口和松耦合代码、控制反转等等的细节。有一些相当令人兴奋的讨论，所以我想借此机会把事情分解一下，以理解为什么界面是有用的。

When I first started getting exposed to interfaces, I too was confused about their relevance. I didn't understand why you needed them. If we're using a language like Java or C#, we already have inheritance and I viewed interfaces as a weaker form of inheritance and thought, "why bother?" In a sense I was right, you can think of interfaces as sort of a weak form of inheritance, but beyond that I finally understood their use as a language construct by thinking of them as a means of classifying common traits or behaviors that were exhibited by potentially many non-related classes of objects.

例如，假设你有一款SIM游戏，并拥有以下类:

class HouseFly inherits Insect {
    void FlyAroundYourHead(){}
    void LandOnThings(){}
}

class Telemarketer inherits Person {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}
}

显然，这两个对象在直接继承方面没有任何共同之处。但是，你可以说它们都很烦人。

让我们假设我们的游戏需要有一些随机的东西让玩家在吃饭时感到厌烦。这可以是HouseFly或Telemarketer，或两者兼而有之，但你如何在一个功能上兼顾两者呢?你如何要求每个不同类型的对象以同样的方式“做他们讨厌的事情”?

要认识到的关键是，Telemarketer和HouseFly都共享一个共同的松散解释的行为，尽管它们在建模方面完全不同。所以，让我们创建一个两者都可以实现的接口:

interface IPest {
    void BeAnnoying();
}

class HouseFly inherits Insect implements IPest {
    void FlyAroundYourHead(){}
    void LandOnThings(){}

    void BeAnnoying() {
        FlyAroundYourHead();
        LandOnThings();
    }
}

class Telemarketer inherits Person implements IPest {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}

    void BeAnnoying() {
        CallDuringDinner();
        ContinueTalkingWhenYouSayNo();
    }
}

我们现在有两个类，每个类都以自己的方式令人讨厌。它们不需要派生于相同的基类，也不需要共享共同的固有特征——它们只需要满足IPest的契约——这个契约很简单。你只需要变得烦人。在这方面，我们可以建立以下模型:

class DiningRoom {

    DiningRoom(Person[] diningPeople, IPest[] pests) { ... }

    void ServeDinner() {
        when diningPeople are eating,

        foreach pest in pests
        pest.BeAnnoying();
    }
}

这里我们有一个餐厅，可以接待许多食客和一些害虫——注意界面的使用。这意味着在我们的小世界中，害虫数组的成员实际上可以是Telemarketer对象或HouseFly对象。

The ServeDinner method is called when dinner is served and our people in the dining room are supposed to eat. In our little game, that's when our pests do their work -- each pest is instructed to be annoying by way of the IPest interface. In this way, we can easily have both Telemarketers and HouseFlys be annoying in each of their own ways -- we care only that we have something in the DiningRoom object that is a pest, we don't really care what it is and they could have nothing in common with other.

这个非常人为的伪代码示例(比我预期的要长得多)只是为了说明一些事情，这些事情最终为我打开了一盏灯，让我知道什么时候可以使用接口。我为这个例子的愚蠢提前道歉，但希望它有助于您的理解。而且，可以肯定的是，您在这里收到的其他回答确实涵盖了当今在设计模式和开发方法中使用接口的全部范围。

下面是一个简单的示例，用于说明如何对航班预订系统进行编程。

//This interface is very flexible and abstract
    addPassenger(Plane seat, Ticket ticket); 

//Boeing is implementation of Plane
    addPassenger(Boeing747 seat, EconomyTicket ticket); 
    addPassenger(Cessna, BusinessClass ticket);


    addPassenger(J15, E87687); 

“编程到接口”意味着不要直接提供硬代码，这意味着你的代码应该在不破坏之前功能的情况下进行扩展。只是扩展，而不是编辑前面的代码。