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

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

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

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

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

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

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

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

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

你应该看看反转控制:

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原则的一种方式。

短篇故事:一个邮递员被要求挨家挨户地接收写有地址的信封(信件、文件、支票、礼品卡、申请书、情书)。

假设没有封面，让邮递员挨家挨户地接收所有的东西，然后交给其他人，邮递员会感到困惑。

所以最好用封面(在我们的故事中是接口)包装它，然后他就会很好地完成他的工作。

现在邮差的工作只是收和送封皮(他不关心封皮里面有什么)。

创建一个接口类型，而不是实际类型，而是使用实际类型实现它。

创建一个接口意味着你的组件可以很容易地适应其余的代码

我给你们举个例子。

你有一个plane界面，如下所示。

interface Airplane{
    parkPlane();
    servicePlane();
}

假设在平面的Controller类中有这样的方法

parkPlane(Airplane plane)

and

servicePlane(Airplane plane)

在您的程序中实现。它不会破坏你的代码。 我的意思是，只要它接受参数plane，它就不需要改变。

因为它将接受任何飞机，不管实际类型，飞行员，高空飞行，战斗机等。

同样，在集合中:

列表> <飞机飞机;//会占用你所有的飞机。

下面的例子将帮助您理解。

---

你有一架战斗机来执行它，所以

public class Fighter implements Airplane {

    public void  parkPlane(){
        // Specific implementations for fighter plane to park
    }
    public void  servicePlane(){
        // Specific implementatoins for fighter plane to service.
    }
}

HighFlyer和其他类也是如此:

public class HighFlyer implements Airplane {

    public void  parkPlane(){
        // Specific implementations for HighFlyer plane to park
    }

    public void  servicePlane(){
        // specific implementatoins for HighFlyer plane to service.
    }
}

现在假设你的控制器类多次使用AirPlane，

假设你的控制器类是ControlPlane，如下所示，

public Class ControlPlane{ 
 AirPlane plane;
 // so much method with AirPlane reference are used here...
}

神奇的是，你可以在不改变ControlPlane类代码的情况下，尽可能多地创建新的AirPlane类型实例。

你可以添加一个实例…

JumboJetPlane // implementing AirPlane interface.
AirBus        // implementing AirPlane interface.

您也可以删除以前创建的类型的实例。