c++的解释。

把接口看作是类的公共方法。

然后你可以创建一个“依赖”于这些公共方法的模板来执行它自己的函数(它在类的公共接口中进行函数调用)。假设这个模板是一个容器，就像Vector类一样，它所依赖的接口是一个搜索算法。

任何定义函数/接口Vector调用的算法类都将满足“契约”(就像有人在原始回复中解释的那样)。算法甚至不需要是相同的基类;唯一的要求是向量所依赖的函数/方法(接口)在你的算法中定义。

所有这些的重点是，您可以提供任何不同的搜索算法/类，只要它提供了Vector所依赖的接口(冒泡搜索、顺序搜索、快速搜索)。

您可能还想设计其他容器(列表、队列)，通过让它们实现搜索算法所依赖的接口/契约，来利用与Vector相同的搜索算法。

这节省了时间(OOP原则“代码重用”)，因为你可以一次编写一个算法，而不是一遍又一遍地针对你创建的每个新对象，而不会因为过度生长的继承树而使问题过于复杂。

至于“错过”事情是如何运作的;这是非常重要的(至少在c++中)，因为这是大多数标准模板库框架的运作方式。

当然，当使用继承和抽象类时，接口编程的方法会发生变化;但原理是一样的，你的公共函数/方法是你的类接口。

这是一个巨大的主题，也是设计模式的基石原则之一。

program to an interface is a term from the GOF book. i would not directly say it has to do with java interface but rather real interfaces. to achieve clean layer separation, you need to create some separation between systems for example: Let's say you had a concrete database you want to use, you would never "program to the database" , instead you would "program to the storage interface". Likewise you would never "program to a Web Service" but rather you would program to a "client interface". this is so you can easily swap things out.

我发现这些规则对我很有帮助:

1. 当我们有多种类型的对象时，我们使用Java接口。如果我只有一个对象，我就看不到意义了。如果某个想法至少有两种具体实现，那么我会使用Java接口。

2. 如果如上所述，您希望从外部系统(存储系统)到自己的系统(本地DB)进行解耦，那么也需要使用接口。

注意有两种方法来考虑何时使用它们。

为了补充现有的帖子，当开发人员同时在不同的组件上工作时，有时对接口进行编码有助于大型项目。您所需要做的就是预先定义接口并为它们编写代码，而其他开发人员则为您正在实现的接口编写代码。

因此，为了做到这一点，接口的优点是我可以将方法的调用与任何特定的类分开。而是创建接口的实例，其中的实现来自我选择的实现该接口的任何类。因此，允许我拥有许多类，它们具有相似但略有不同的功能，并且在某些情况下(与接口的意图相关的情况)并不关心它是哪个对象。

例如，我可以有一个移动界面。一个方法可以让一些东西“移动”，任何实现移动接口的对象(Person, Car, Cat)都可以被传递进来并被告知移动。如果每个方法都不知道类的类型，那么它就是类。

即使当我们不依赖于抽象时，面向接口编程也是有利的。

接口编程迫使我们使用对象的上下文适当的子集。这很有用，因为它:

防止我们做一些不合时宜的事，还有 让我们在将来安全地更改实现。

例如，考虑实现Friend和Employee接口的Person类。

class Person implements AbstractEmployee, AbstractFriend {
}

在这个人的生日的情况下，我们编程到朋友界面，以防止像对待员工一样对待这个人。

function party() {
    const friend: Friend = new Person("Kathryn");
    friend.HaveFun();
}

在这个人的工作环境中，我们对雇员界面进行编程，以防止模糊工作场所的边界。

function workplace() {
    const employee: Employee = new Person("Kathryn");
    employee.DoWork();
}

太好了。我们在不同的环境中都有适当的表现，我们的软件运行良好。

在遥远的未来，如果我们的业务改变为与狗打交道，我们可以相当容易地更改软件。首先，我们创建一个实现Friend和Employee的Dog类。然后，我们安全地将新的Person()更改为新的Dog()。即使两个函数都有数千行代码，这个简单的编辑也可以工作，因为我们知道以下是正确的:

Function party只使用Person的Friend子集。 函数workplace只使用Person的Employee子集。 类Dog实现了Friend和Employee接口。

另一方面，如果任何一方或工作场所都针对Person进行编程，就会有同时拥有特定于Person的代码的风险。从“人”改为“狗”需要我们梳理代码，删除任何“狗”不支持的“人”特定代码。

寓意:为接口编程可以帮助我们的代码适当地运行，并为更改做好准备。它还使我们的代码能够依赖于抽象，这带来了更多的好处。

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

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

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

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

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

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

我给你们举个例子。

你有一个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.

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