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

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

“编程到接口”意味着不要直接提供硬代码，这意味着你的代码应该在不破坏之前功能的情况下进行扩展。只是扩展，而不是编辑前面的代码。

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

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

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

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

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

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

我给你们举个例子。

你有一个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.

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

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

此外，我在这里看到了很多很好的解释性答案，所以我想在这里给出我的观点，包括一些我在使用这种方法时注意到的额外信息。

单元测试

在过去的两年里，我写了一个业余项目，但我没有为它写单元测试。在写了大约50K行代码后，我发现编写单元测试是非常必要的。 我没有使用接口(或者很少使用)……当我做第一个单元测试时，我发现它很复杂。为什么?

因为我必须创建大量的类实例，用作类变量和/或参数的输入。所以测试看起来更像集成测试(必须制作一个完整的类“框架”，因为所有的类都捆绑在一起)。

界面恐惧 所以我决定使用接口。我担心的是我必须在所有地方(在所有使用的类中)多次实现所有功能。在某种程度上，这是正确的，然而，通过使用继承，它可以减少很多。

接口和继承的组合 我发现这个组合很好用。我举一个非常简单的例子。

public interface IPricable
{
    int Price { get; }
}

public interface ICar : IPricable

public abstract class Article
{
    public int Price { get { return ... } }
}

public class Car : Article, ICar
{
    // Price does not need to be defined here
}

这样就不需要复制代码，同时仍然有使用汽车作为接口(ICar)的好处。

在Java中，这些具体类都实现了CharSequence接口:

神健壮健壮健壮健壮

除了Object之外，这些具体的类没有共同的父类，因此它们之间没有任何联系，除了它们各自都与字符数组有关，表示或操作这些字符。例如，String对象实例化后，String的字符不能被更改，而StringBuffer或StringBuilder的字符可以被编辑。

然而，这些类中的每一个都能够适当地实现CharSequence接口方法:

char charAt(int index)
int length()
CharSequence subSequence(int start, int end)
String toString()

在某些情况下，曾经接受String的Java类库类已经修改为现在接受CharSequence接口。因此，如果你有一个StringBuilder实例，而不是提取一个String对象(这意味着实例化一个新的对象实例)，它可以在实现CharSequence接口时直接传递StringBuilder本身。

某些类实现的Appendable接口对于任何可以将字符追加到底层具体类对象实例的实例的情况都具有大致相同的好处。所有这些具体类都实现了Appendable接口:

BufferedWriter, CharArrayWriter, CharBuffer, FileWriter, FilterWriter, LogStream, OutputStreamWriter, PipedWriter, PrintStream, PrintWriter, StringBuffer, StringBuilder, StringWriter, Writer