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

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

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

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

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

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

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

有很多解释，但让它更简单。以List为例。可以使用as实现一个列表:

内部数组 链表 其他实现

通过构建一个接口，比如一个List。您只编写了List的定义或List在实际中的含义。

你可以在内部使用任何类型的实现比如数组实现。但是假设您希望由于某种原因(比如bug或性能)更改实现。然后你只需要改变声明List<String> ls = new ArrayList<String>()为List<String> ls = new LinkedList<String>()。

在代码的其他地方，你不需要改变任何东西;因为其他所有东西都建立在List的定义之上。

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

它的实际意思是:

===

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

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

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

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

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

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

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

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

面向接口而不是实现的代码与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接口与“面向接口编程，而不是面向实现”的概念有什么关系。它们可以帮助应用概念，但它们不是概念。

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

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

作为一名程序员(使用任何语言)，我的脑海中始终有一个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原则的一种方式。