让我们先从一些定义开始:

一个对象的操作所定义的所有签名的集合称为该对象的接口

输入n.指定接口

上面定义的接口的一个简单例子是所有PDO对象方法，如query()、commit()、close()等，作为一个整体，而不是分开。这些方法，即它的接口定义了可以发送到对象的完整消息和请求集。

上面定义的类型是一个特定的接口。我将使用创建的形状界面来演示:draw()， getArea()， getPerimeter()等。

如果一个对象是Database类型的，我们的意思是它接受数据库接口、query()、commit()等的消息/请求。对象可以有多种类型。只要实现了接口，就可以让数据库对象具有形状类型，在这种情况下，这将是子类型。

许多对象可以是许多不同的接口/类型，并以不同的方式实现该接口。这允许我们替换对象，让我们选择使用哪个对象。也称为多态性。

客户机将只知道接口，而不知道实现。

因此，从本质上讲，编程到一个接口将涉及到一些类型的抽象类，如只指定接口的Shape，即draw()， getCoordinates()， getArea()等。然后让不同的具体类实现这些接口，比如圆形类，方形类，三角形类。因此，针对接口而不是实现编程。

为一个界面编码是一种哲学，而不是特定的语言结构或设计模式——它指导你为了创建更好的软件系统而遵循正确的步骤顺序(例如，更有弹性，更可测试，更可伸缩，更可扩展，以及其他良好的特性)。

它的实际意思是:

===

在跳到实现和编码(如何)之前，先想想是什么:

你的系统中应该有哪些黑箱， 每个盒子的职责是什么? 每个“客户端”(即其他盒子，第三方“盒子”，甚至人类)应该与它(每个盒子的API)通信的方式是什么?

在你理清上面的问题之后，继续执行这些方框(HOW)。

首先考虑什么是盒子，什么是它的API，这将引导开发人员提炼盒子的职责，并为自己和未来的开发人员标记它的公开细节(“API”)和隐藏细节(“实现细节”)之间的区别，这是一个非常重要的区别。

一个直接且容易注意到的收获是，团队可以在不影响总体架构的情况下更改和改进实现。它还使系统更具可测试性(它与TDD方法配合得很好)。

= = = 除了我上面提到的特质，你还可以在这个方向上节省很多时间。

微服务和DDD，如果做得正确，是“编码到接口”的很好的例子，然而这个概念在每个模式中获胜，从巨石到“无服务器”，从BE到FE，从面向对象到功能性，等等....

我强烈推荐这种方法用于软件工程(我基本上相信它在其他领域也完全有意义)。

假设你有一个名为“Zebra”的产品，可以通过插件进行扩展。它通过在某个目录中搜索dll来查找插件。它加载所有这些dll，并使用反射来查找实现IZebraPlugin的任何类，然后调用该接口的方法来与插件通信。

这使得它完全独立于任何特定的插件类——它不关心类是什么。它只关心它们是否满足接口规范。

接口是这样定义可扩展性点的一种方式。与接口对话的代码是松散耦合的——事实上，它与任何其他特定的代码根本不耦合。它可以与多年后由从未见过原始开发人员的人编写的插件进行互操作。

你可以使用一个带有虚函数的基类——所有的插件都是从基类派生的。但这有很大的限制，因为一个类只能有一个基类，而它可以实现任意数量的接口。

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

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

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.

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

当您拥有一组类似的类时，它使您的代码更具可扩展性，更容易维护。我是一个初级程序员，所以我不是专家，但我刚刚完成了一个需要类似东西的项目。

我从事与运行医疗设备的服务器对话的客户端软件工作。我们正在开发这种设备的新版本，其中有一些新组件，客户必须不时进行配置。有两种类型的新组件，它们是不同的，但也非常相似。基本上，我必须创建两个配置表单，两个列表类，所有东西都要创建两个。

我决定最好是为每个控件类型创建一个抽象基类，它可以容纳几乎所有的实际逻辑，然后是派生类型，以处理两个组件之间的差异。然而，如果我不得不一直担心类型，基类就不能在这些组件上执行操作(好吧，它们可以，但每个方法中都有一个“if”语句或开关)。

我为这些组件定义了一个简单的接口，所有基类都与该接口对话。现在当我改变一些东西，它几乎“只是工作”在任何地方，我没有代码复制。