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

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

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

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

接口类似于契约，您希望实现类实现在契约(接口)中编写的方法。由于Java不提供多重继承，“编程到接口”是实现多重继承的好方法。

如果您有一个类a，它已经扩展了其他一些类B，但是您希望这个类a也遵循某些指导方针或实现某个契约，那么您可以通过“编程到接口”策略来实现。

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

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

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

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

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

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

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

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

c++的解释。

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

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

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

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

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

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

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

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

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

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

它的实际意思是:

===

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

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

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

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

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

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

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

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

Using interfaces is a key factor in making your code easily testable in addition to removing unnecessary couplings between your classes. By creating an interface that defines the operations on your class, you allow classes that want to use that functionality the ability to use it without depending on your implementing class directly. If later on you decide to change and use a different implementation, you need only change the part of the code where the implementation is instantiated. The rest of the code need not change because it depends on the interface, not the implementing class.

This is very useful in creating unit tests. In the class under test you have it depend on the interface and inject an instance of the interface into the class (or a factory that allows it to build instances of the interface as needed) via the constructor or a property settor. The class uses the provided (or created) interface in its methods. When you go to write your tests, you can mock or fake the interface and provide an interface that responds with data configured in your unit test. You can do this because your class under test deals only with the interface, not your concrete implementation. Any class implementing the interface, including your mock or fake class, will do.

编辑:下面是一篇文章的链接，其中Erich Gamma讨论了他的引用，“面向接口编程，而不是面向实现编程。”

http://www.artima.com/lejava/articles/designprinciples.html