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

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

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

它也适用于单元测试，你可以将你自己的类(满足接口的要求)注入到依赖它的类中

前面的回答主要关注为了可扩展性和松耦合而对抽象进行编程。虽然这些都很重要， 可读性同样重要。可读性允许其他人(以及您未来的自己)以最小的努力理解代码。这就是可读性利用抽象的原因。

根据定义，抽象比实现更简单。抽象省略了细节以传达事物的本质或目的，仅此而已。 由于抽象更简单，与实现相比，我可以一次在脑海中容纳更多的抽象。

作为一名程序员(使用任何语言)，我的脑海中始终有一个List的大致概念。特别是，List允许随机访问、重复元素并保持顺序。当我看到这样的声明:List myList = new ArrayList()我想，很酷，这是一个以我理解的(基本)方式使用的List;我就不用再想了

On the other hand, I do not carry around the specific implementation details of ArrayList in my head. So when I see, ArrayList myList = new ArrayList(). I think, uh-oh, this ArrayList must be used in a way that isn't covered by the List interface. Now I have to track down all the usages of this ArrayList to understand why, because otherwise I won't be able to fully understand this code. It gets even more confusing when I discover that 100% of the usages of this ArrayList do conform to the List interface. Then I'm left wondering... was there some code relying on ArrayList implementation details that got deleted? Was the programmer who instantiated it just incompetent? Is this application locked into that specific implementation in some way at runtime? A way that I don't understand?

我现在对这个应用程序感到困惑和不确定，我们所讨论的只是一个简单的List。如果这是一个忽略其接口的复杂业务对象呢?那么我的业务领域知识不足以理解代码的目的。

因此，即使当我在私有方法中严格需要List时(如果它改变了，不会破坏其他应用程序，并且我可以很容易地找到/替换IDE中的每个用法)，它仍然有利于编程到抽象的可读性。因为抽象比实现细节更简单。您可以说，对抽象进行编程是遵循KISS原则的一种方式。

我是这个问题的后来者，但我想在这里提到的是，在GoF (Gang of Four)设计模式一书中，“为接口编程，而不是为实现编程”这一行有一些很好的讨论。

它在第18页说:

针对接口编程，而不是针对实现编程 不要将变量声明为特定具体类的实例。相反，只提交到由抽象类定义的接口。你会发现这是本书设计模式的一个共同主题。

在此之上，它是这样开始的:

仅根据抽象类定义的接口来操作对象有两个好处: 客户端仍然不知道他们使用的对象的具体类型，只要对象遵循客户端期望的接口。 客户端仍然不知道实现这些对象的类。客户端只知道定义接口的抽象类。

So in other words, don't write it your classes so that it has a quack() method for ducks, and then a bark() method for dogs, because they are too specific for a particular implementation of a class (or subclass). Instead, write the method using names that are general enough to be used in the base class, such as giveSound() or move(), so that they can be used for ducks, dogs, or even cars, and then the client of your classes can just say .giveSound() rather than thinking about whether to use quack() or bark() or even determine the type before issuing the correct message to be sent to the object.

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

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

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

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