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

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

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

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

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

它的实际意思是:

===

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

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

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

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

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

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

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

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

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

单元测试

在过去的两年里，我写了一个业余项目，但我没有为它写单元测试。在写了大约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)的好处。

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

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

听起来好像你知道接口是如何工作的，但不确定何时使用它们以及它们提供了什么优势。下面是几个例子，说明界面是有意义的:

// if I want to add search capabilities to my application and support multiple search
// engines such as Google, Yahoo, Live, etc.

interface ISearchProvider
{
    string Search(string keywords);
}

然后我可以创建GoogleSearchProvider, YahooSearchProvider, LiveSearchProvider等。

// if I want to support multiple downloads using different protocols
// HTTP, HTTPS, FTP, FTPS, etc.
interface IUrlDownload
{
    void Download(string url)
}

// how about an image loader for different kinds of images JPG, GIF, PNG, etc.
interface IImageLoader
{
    Bitmap LoadImage(string filename)
}

然后创建JpegImageLoader, GifImageLoader, PngImageLoader等。

大多数外接程序和插件系统都离不开接口。

另一种流行的用法是Repository模式。假设我想从不同的来源加载一个邮政编码列表

interface IZipCodeRepository
{
    IList<ZipCode> GetZipCodes(string state);
}

然后我可以创建一个XMLZipCodeRepository, SQLZipCodeRepository, CSVZipCodeRepository等。对于我的web应用程序，我经常在早期创建XML存储库，这样我就可以在SQL数据库准备好之前启动并运行一些东西。一旦数据库准备好了，我就编写一个SQLRepository来替换XML版本。我的其余代码保持不变，因为它完全基于接口运行。

方法可以接受如下接口:

PrintZipCodes(IZipCodeRepository zipCodeRepository, string state)
{
    foreach (ZipCode zipCode in zipCodeRepository.GetZipCodes(state))
    {
        Console.WriteLine(zipCode.ToString());
    }
}

我是这个问题的后来者，但我想在这里提到的是，在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.