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

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方法中所做的更改不会强制您更改调用代码。

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

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

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

问:——……“你能使用任何实现接口的类吗?” A:是的。 问:——……“你什么时候需要这样做?” 答:-每次你都需要一个实现接口的类。

注意:我们不能实例化一个没有被类实现的接口- True。

为什么? 因为接口只有方法原型，没有定义(只有函数名，没有它们的逻辑)

AnIntf anInst = new class(); //我们可以这样做，只有当类实现AnIntf。 // anInst将有类引用。

注意:现在我们可以理解如果Bclass和Cclass实现相同的Dintf会发生什么。

Dintf bInst = new Bclass();  
// now we could call all Dintf functions implemented (defined) in Bclass.

Dintf cInst = new Cclass();  
// now we could call all Dintf functions implemented (defined) in Cclass.

我们拥有:相同的接口原型(接口中的函数名)，调用不同的实现。

参考书目: 原型——维基百科

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

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

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

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

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)进行解耦，那么也需要使用接口。

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

c++的解释。

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

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

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

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

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

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

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

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

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