面向接口而不是实现的代码与Java无关，也与它的接口构造无关。

这个概念是在模式/四人帮的书中突出的，但很可能在那之前就已经存在了。这个概念在Java出现之前就已经存在了。

Java Interface构造的创建就是为了帮助实现这一想法(以及其他一些事情)，人们过于关注作为意义中心的构造，而不是最初的意图。然而，这也是为什么我们在Java、c++、c#等语言中有公共和私有方法和属性的原因。

It means just interact with an object or system's public interface. Don't worry or even anticipate how it does what it does internally. Don't worry about how it is implemented. In object-oriented code, it is why we have public vs. private methods/attributes. We are intended to use the public methods because the private methods are there only for use internally, within the class. They make up the implementation of the class and can be changed as required without changing the public interface. Assume that regarding functionality, a method on a class will perform the same operation with the same expected result every time you call it with the same parameters. It allows the author to change how the class works, its implementation, without breaking how people interact with it.

And you can program to the interface, not the implementation without ever using an Interface construct. You can program to the interface not the implementation in C++, which does not have an Interface construct. You can integrate two massive enterprise systems much more robustly as long as they interact through public interfaces (contracts) rather than calling methods on objects internal to the systems. The interfaces are expected to always react the same expected way given the same input parameters; if implemented to the interface and not the implementation. The concept works in many places.

不要认为Java接口与“面向接口编程，而不是面向实现”的概念有什么关系。它们可以帮助应用概念，但它们不是概念。

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

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

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

例如，考虑实现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的代码的风险。从“人”改为“狗”需要我们梳理代码，删除任何“狗”不支持的“人”特定代码。

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

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

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

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.

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

我坚信困难的问题应该用现实世界中简单的答案来解释。在软件设计领域，这是非常重要的。

看看你家里、学校、教堂的任何一扇门……任何建筑。

想象一下，有些门的底部有危险(所以你必须鞠躬才能与开门或关门的门互动)，

或者其他人只能坐在左上角(所以，一些侏儒、残疾人或凯文·哈特不会觉得这种门很有趣，也不会觉得它很好用)。

所以设计是关键，创建程序让其他人可以开发/使用它。

接口的作用是让大型项目中的初级/高级开发人员更容易工作，这样每个人都知道自己在做什么，而不需要别人的帮助，这样你就可以尽可能顺利地工作(理论上)。

[1]:如何?通过揭示价值的形态。所以，你不需要文档，因为代码本身是不言自明的(棒极了)。

这个答案并不是针对特定语言的，而是概念驱动的(毕竟，人类是通过编写代码来创建工具的)。

我曾经给学生的一个具体例子是他们应该写作

List myList = new ArrayList(); // programming to the List interface

而不是

ArrayList myList = new ArrayList(); // this is bad

在一个短程序中，它们看起来完全相同，但如果在程序中继续使用myList 100次，就会开始看到区别。第一个声明确保只调用myList上由List接口定义的方法(因此没有ArrayList特定的方法)。如果您以这种方式对接口进行了编程，那么稍后您就可以确定您确实需要

List myList = new TreeList();

你只需要在这一点上修改代码。您已经知道，其余的代码不会因为更改实现而被破坏，因为您对接口进行了编程。

当您谈论方法参数和返回值时，好处甚至更明显(我认为)。举个例子:

public ArrayList doSomething(HashMap map);

该方法声明将您绑定到两个具体实现(ArrayList和HashMap)。一旦从其他代码调用该方法，对这些类型的任何更改都可能意味着您将不得不更改调用代码。最好是根据接口进行编程。

public List doSomething(Map map);

现在，不管您返回什么样的List，或者作为参数传入什么样的Map。在doSomething方法中所做的更改不会强制您更改调用代码。