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

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

c++的解释。

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

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

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

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

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

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

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

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

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

你应该看看反转控制:

Martin Fowler:控制反转容器和依赖注入模式 维基百科:控制反转

在这种情况下，你不会这样写:

IInterface classRef = new ObjectWhatever();

你可以这样写:

IInterface classRef = container.Resolve<IInterface>();

这将进入容器对象中基于规则的设置，并为您构造实际对象，该对象可以是ObjectWhatever。重要的是，您可以将此规则替换为完全使用另一种类型对象的规则，而您的代码仍然可以工作。

如果我们不考虑IoC，那么您可以编写的代码知道它可以与执行特定操作的对象进行对话，但不知道是哪种类型的对象或它如何执行操作。

这将在传递参数时派上用场。

至于你带圆括号的问题“另外，你如何编写一个方法来接受一个实现接口的对象?”这可能吗?”，在c#中，你可以简单地使用接口类型作为参数类型，如下所示:

public void DoSomethingToAnObject(IInterface whatever) { ... }

这直接插入到“与做特定事情的对象对话”中。上面定义的方法知道从对象中期望得到什么，它实现了IInterface中的所有内容，但它并不关心它是哪种类型的对象，只关心它遵守契约，这就是接口。

例如，你可能对计算器很熟悉，也可能在你的生活中使用过不少计算器，但大多数时候它们都是不同的。另一方面，你知道标准计算器应该如何工作，所以你能够使用所有的计算器，即使你不能使用每个计算器都没有的特定功能。

这就是界面的美妙之处。你可以写一段代码，它知道它会得到传递给它的对象，它可以从这些对象中期待特定的行为。它并不关心它是什么类型的对象，只关心它支持所需的行为。

让我给你一个具体的例子。

我们为windows窗体定制了翻译系统。这个系统循环遍历表单上的控件，并翻译每个控件中的文本。这个系统知道如何处理基本的控件，比如拥有文本属性的控件类型，以及类似的基本东西，但对于任何基本的东西，它都做不到。

现在，由于控件继承自我们无法控制的预定义类，我们可以做以下三件事之一:

为我们的翻译系统提供支持，以检测它正在使用哪种类型的控件，并翻译正确的位(维护的噩梦) 将支持构建到基类中(不可能，因为所有控件都继承自不同的预定义类) 添加接口支持

所以是nr. 3。我们所有的控件都实现了ILocalizable，这是一个提供给我们一个方法的接口，能够将“本身”转换为翻译文本/规则的容器。因此，表单不需要知道它找到了哪种类型的控件，只需要知道它实现了特定的接口，并且知道可以调用某个方法来本地化该控件。

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

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

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

问:——……“你能使用任何实现接口的类吗?” 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.

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

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