“程序”到接口的含义是什么？

Question

我已经看到了几次提到的，但我不清楚它的含义。何时，为什么要这样做？

我知道界面有什么作用，但是我不清楚的事实使我认为我错过了正确使用它们。

是这样做的：

IInterface classRef = new ObjectWhatever()

您可以使用任何实现 iinterface 的类？您什么时候需要这样做？我唯一能想到的是，如果您有一种方法，并且不确定将传递哪些对象，除了IT实现 iinterface 。我认为您需要多久做一次。

另外，您如何编写一种使用实现接口的对象的方法？有可能吗？

Answer 1

想象一下，您有一种称为“斑马”的产品，可以通过插件扩展。它通过在某些目录中搜索DLL来找到插件。它加载了所有这些DLL，并使用反射来找到实现 izebraplugin 的任何类，然后调用该接口的方法与插件进行通信。

这使其完全独立于任何特定的插件类 - 它不在乎类是什么。它只关心他们满足接口规范。

接口是定义这样的可扩展性点的一种方式。与接口进行交谈的代码更加松散地耦合 - 实际上，它根本没有与任何其他特定代码结合在一起。它可以与从未见过原始开发人员遇到的人撰写的插件相互互操作。

取而代之的是，您可以使用具有虚拟功能的基类 - 所有插件都将从基类派生。但这是更大的限制，因为类只能具有一个基类，而它可以实现任何数量的接口。

Answer 2

C ++解释。

将界面视为您的类公共方法。

然后，您可以创建一个模板，该模板“取决于”这些公共方法以执行其自己的函数（在类公共接口中定义了函数调用）。假设此模板是一个容器，例如向量类，其依赖的接口是搜索算法。

任何定义函数/接口向量的算法类都可以呼叫以满足“合同”（正如某人在原始答复中所解释的那样）。这些算法甚至不需要是同一基类。唯一的要求是，在算法中定义了向量取决于（接口）的函数/方法。

所有这些的目的是，您可以提供任何不同的搜索算法/类，只要它提供了向量依赖的接口（气泡搜索，顺序搜索，快速搜索）。

您可能还需要设计其他容器（列表，队列），这些容器可以通过使搜索算法依赖于搜索算法的接口/合同来利用与向量相同的搜索算法。

这节省了时间（oop原理“代码重复使用”），因为您能够一次又一次地编写算法，而不是一次又一次地特定于您创建的每个新对象，而不会用过度生长的继承树过度复杂问题。

至于事物的运作方式“错过”；大型时间（至少在C ++中），因为这是大多数标准模板库的框架的运作方式。

当然，当使用继承和抽象类时，编程到接口的方法会更改；但是原理是相同的，您的公共功能/方法是您的类接口。

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

Answer 3

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

charbuffer，string，StringBuffer，StringBuilder

这些具体类除了对象以外没有其他父母类别，因此除了它们每个人都与字符的数组有关，代表这样的事实或操纵此类此类事实以外，没有任何关系。例如，一旦实例化字符串对象，就无法更改字符串的字符，而可以编辑StringBuffer或StringBuilder的字符。

然而，这些类中的每个类都可以适当地实现CharSequence接口方法：

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

在某些情况下，已对字符串的Java类库类已修改为现在接受CharSequence接口。因此，如果您具有StringBuilder的实例，而不是提取字符串对象（这意味着实例化新对象实例），而是可以在实现CharSequence接口时传递StringBuilder本身。

对于任何情况下，可以将字符附加到基础混凝土类对象实例的实例的任何情况下，某些类实现的辅助接口具有相同的好处。所有这些具体类都实现了附加界面：

BufferedWriter，Chararraywriter，Charbuffer，Filewriter，FilterWriter，LogStream，utputStreamWriter，PipedWriter，PipedWriter，PrintStream，PrintStream，printwriter，StringBuffer，StringBuilder，StringBuilder，String Writer，Writer

>

Answer 4

界面的程序是GOF书籍中的一个术语。我不会直接说这与Java接口有关，而是真正的接口。为了实现干净的图层分离，您需要在系统之间创建一些分离：例如，假设您有一个要使用的具体数据库，您永远不会“到数据库”，而是将“对存储接口”进行“程序”。同样，您永远不会“编程到Web服务”，而是将其编程到“客户端接口”。这样您就可以轻松地将内容交换。

我发现这些规则对我有帮助：

1 。当我们拥有多种类型的对象时，我们使用Java接口。如果我只有一个对象，我看不到这一点。如果至少有两个具体的想法实现，那么我将使用Java接口。

2 。如果如上所述，您想将与外部系统（存储系统）的分离带到您自己的系统（本地DB），然后还使用接口。

注意如何考虑何时使用它们的方法。

Answer 5

接口就像合同，您希望您的实现类实现合同中编写的方法（接口）。由于Java没有提供多种继承，因此“编程到接口”是实现多重继承的好方法。

如果您有一个已经扩展了其他B类的A类，但是您希望该类也遵循某些准则或执行某个合同，那么您可以通过“编程到接口”策略来做到这一点。

Answer 6

Q： - ...“您可以使用任何实现接口的类吗？”
答： - 是。

问： - ...“您什么时候需要这样做？”
答： - 每次需要一个实现接口的类。

注意： 我们无法实例化类未实现的接口 - true。

• 为什么？
• 因为界面仅具有方法原型，而不具有定义（仅功能名称，而不是其逻辑）

anintf aninst = new Aclass（）;
// 我们只有在 Aclass实现Anintf的情况下才能执行此操作。
// ANINST将具有aclass参考。

---

注意： 现在，我们可以理解如果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.

我们拥有的内容：相同的接口原型（界面中的函数名称）并调用不同的实现。

参考书目：
prototypes -wikipedia

Answer 7

编码界面是一种理念，而不是特定的语言构造或设计模式 - 它指示您要遵循的正确步骤顺序，以创建更好的软件系统 （例如，更具弹性，更可检验，更可扩展，更扩展和其他良好的特征）。

实际上是：

====

在跳入实现和编码（How）之前 - 想到什么：

• 黑匣子应该构成您的系统，
• 什么是每个盒子的责任，
• 每个“客户”（即其他盒子之一，第三方“盒子”，甚至人类）应与之交流（每个盒子的API）的方式。

在之后，您可以弄清楚上述内容，然后继续实现这些框（如何）。

首先思考一个盒子'是什么，以及它的API，导致开发人员将盒子的责任提高，并为自己和未来的开发人员标记其暴露的细节（“ API”）与它的隐藏细节（​​”实施细节”），这是一个非常重要的差异化。

一个即时且容易明显的收益是团队可以在不影响一般体系结构的情况下改变和改善实现。它还使系统更容易测试（与TDD方法搭配得很好）。

===
除了我上面提到的特征之外，您还节省了很多时间朝这个方向发展。

Micro Services和DDD正确完成时，是“编码到接口”的绝佳示例，但是该概念以从巨石到“无server be to fe，从OOP到功能等”等的每种模式赢得了胜利

。强烈建议使用这种软件工程方法（我基本上认为这在其他领域也是完全有意义的）。

Answer 8

将接口的程序允许更改由接口定义的合同的实现。它允许在合同和特定实现之间散布耦合。

iinterface classRef = new object what what what what whate（）

您可以使用任何实现Iinterface的类？您什么时候需要这样做？

以一个很好的例子来看一下这个问题。

为什么要与Java类互动首选？

使用接口命中性能？

如果是多少？

是的。在子秒中，它将在开销中略有性能。但是，如果您的应用程序需要动态更改接口的实现，请不要担心性能影响。

如何避免它而不必维护两个代码？

如果您的应用程序需要，请勿尝试避免多个接口的实现。如果没有一个特定的实现接口的紧密耦合，则可能必须部署补丁以将一个实现更改为另一个实现。

一种好的用例：策略模式的实施：

Answer 9

“接口程序”是指无法正确提供硬码，这意味着您的代码应在不破坏先前功能的情况下扩展。只是扩展，而不是编辑上一个代码。

Answer 10

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

单位测试

在过去两年中，我写了一个爱好项目，但我没有为此编写单位测试。在写了大约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）的好处。

Answer 11

这里有一些很棒的答案，这些问题涉及有关接口和松散耦合代码，控制倒置等的各种细节。有一些相当令人愉悦的讨论，所以我想借此机会分解一些东西，以了解为什么界面有用。

当我第一次开始接触界面时，我也对它们的相关性感到困惑。我不明白你为什么需要它们。如果我们使用诸如Java或C＃之类的语言，我们已经具有继承，我将接口视为弱的继承和思想形式，“为什么要打扰？”从某种意义上说，我是对的，您可以将界面视为一种薄弱的继承形式，但是除此之外潜在的许多非相关对象类别。

例如 - 假设您有一个SIM卡游戏，并且有以下类：

class HouseFly inherits Insect {
    void FlyAroundYourHead(){}
    void LandOnThings(){}
}

class Telemarketer inherits Person {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}
}

显然，这两个对象在直接继承方面没有任何共同点。但是，您可以说他们都很烦人。

假设我们的游戏需要有某种随机的东西在吃晚餐时会惹恼游戏玩家。这可能是 Housefly 或 Telemarketer 或两者兼而有之 - 但是您如何使用一个功能允许两者兼而有之呢？您如何以相同的方式要求每种不同类型的对象“做他们烦人的事情”？

要意识到的关键是，电话推销和 housefly 共享一个常见的松散解释的行为，即使它们在建模方面绝不相似。因此，让我们制作一个可以实现的接口：

interface IPest {
    void BeAnnoying();
}

class HouseFly inherits Insect implements IPest {
    void FlyAroundYourHead(){}
    void LandOnThings(){}

    void BeAnnoying() {
        FlyAroundYourHead();
        LandOnThings();
    }
}

class Telemarketer inherits Person implements IPest {
    void CallDuringDinner(){}
    void ContinueTalkingWhenYouSayNo(){}

    void BeAnnoying() {
        CallDuringDinner();
        ContinueTalkingWhenYouSayNo();
    }
}

我们现在有两个类，每个类都可以以自己的方式感到烦人。而且他们不需要从同一基类来衍生并共享共同的固有特征 - 他们只需要满足 ipest 的合同 - 合同很简单。您只需要 beannoying 。在这方面，我们可以对以下内容进行建模：

class DiningRoom {

    DiningRoom(Person[] diningPeople, IPest[] pests) { ... }

    void ServeDinner() {
        when diningPeople are eating,

        foreach pest in pests
        pest.BeAnnoying();
    }
}

在这里，我们有一个餐厅，可以接受许多食客和许多害虫 - 请注意使用该界面。这意味着，在我们的小世界中，害虫的成员数组实际上可以是 Telemarketer 对象或 Housefly 对象。

serveinner 方法在晚餐时被称为，我们的饭厅里的人应该吃。在我们的小游戏中，那是我们的害虫完成工作的时候 - 每个害虫都被指示通过 ipest 接口感到烦人。这样，我们可以很容易地拥有 Telemarketers 和 Houseflys 以每种方式都很烦人 - 我们只关心我们在餐厅中有东西< /code>是害虫的对象，我们并不真正在乎它是什么，它们与他人无关。

这个非常人为的伪代码示例（在我预期的时间比我预期的要长得多）只是为了说明那种最终从何时使用界面来为我开启的东西。对于这个例子的愚蠢，我提前道歉，但希望它有助于您的理解。而且，可以肯定的是，您在此处收到的其他发布的答案确实涵盖了当今在设计模式和开发方法中使用界面的范围。

Answer 12

我用来给学生给学生的具体示例是，他们应该在简短的程序中写下

List myList = new ArrayList(); // programming to the List interface

这些

ArrayList myList = new ArrayList(); // this is bad

外观，但如果您继续在程序中使用 myList 100次，则可以开始看到差异。第一个声明可确保您仅在 myList 上调用方法，该方法由 list 接口定义（因此no arraylist 特定方法）。如果您以这种方式编程到界面，则稍后您可以决定确实需要

List myList = new TreeList();

，只需要在该位置更改代码即可。您已经知道，其余代码不会通过更改实现而破坏的任何事情，因为您已编程为接口。

当您谈论方法参数和返回值时，好处更为明显（我认为）。以此为例：

public ArrayList doSomething(HashMap map);

该方法声明将您与两个具体实现相关联（ arraylist 和 hashmap ）。一旦从其他代码调用该方法，对这些类型的任何更改都可能意味着您也必须更改调用代码。更好地编程到接口。

public List doSomething(Map map);

现在，您返回哪种 list map 作为参数传递。您在 dosomething 方法中所做的更改不会迫使您更改调用代码。

Answer 13

界面上的编程说：“我需要此功能，我不在乎它来自何处。”

考虑（在Java中）， list 接口与 arraylist 和 linkedlist 混凝土类。如果我关心的只是我有一个数据结构，其中包含我应该通过迭代访问的多个数据项，我会选择 list （这是99％的时间）。如果我知道我需要从列表的任何一端中恒定插入/删除，我可能会选择 linkedlist 具体实现（或更可能，使用 queue 接口）。如果我知道我需要通过索引随机访问，我会选择 arraylist 具体类。

Answer 14

对接口进行编程与我们在Java或.NET中看到的抽象接口无关。这甚至不是OOP概念。

这意味着不要与对象或数据结构的内部杂乱无章。使用抽象程序接口或API与您的数据进行交互。在Java或C＃中，意味着使用公共属性和方法而不是原始字段访问。对于C，意味着使用函数而不是原始指针。

编辑：，使用数据库意味着使用视图和存储过程而不是直接访问。

Answer 15

使用接口是使您的代码易于测试的关键因素，除了删除类之间的不必要的耦合。通过创建一个定义类上操作的界面，您允许类似于使用该功能的类，而无需直接依赖实现类，可以使用它。如果以后您决定更改和使用其他实现，则只需要更改实例实例化的代码部分即可。代码的其余部分不需要更改，因为它取决于接口，而不是实现类。

这对于创建单元测试非常有用。在正在测试的类中，您将其取决于接口，并将接口的实例注入类（或允许其根据需要构建接口实例的工厂）通过构造函数或属性settor构建界面实例。该类在其方法中使用提供的（或创建）接口。当您编写测试时，您可以模拟或伪造接口，并提供一个接口，该接口在单元测试中配置的数据响应。您可以这样做，因为您正在测试的课程仅与接口有关，而不是您的具体实现。任何实现界面的类，包括您的模拟或假班，都可以做到。

编辑：以下是一篇文章的链接，埃里希·伽玛（Erich Gamma）讨论了他的报价“界面的程序，而不是实现”。

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

Answer 16

您应该研究控制的反转：

• Martin Fowler：倒置控制容器和依赖性注入模式
• wikipedia：wikipedia：control

在这种情况下，您不会写这篇文章

IInterface classRef = new ObjectWhatever();

：类似的内容：

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

这将进入 container 对象中的基于规则的设置，并为您构造实际对象，这可能是对象的。重要的是，您可以用完全使用其他类型对象的东西替换此规则，并且您的代码仍然可以使用。

如果我们将IOC放在桌子上，您可以编写知道它可以与对象进行特定的对象的代码，但不能与对象进行交谈，但不能与哪种类型的对象或如何做。

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

至于您的括号问题：“另外，您如何编写一种使用实现接口的对象的方法？这是可能的吗？”，在C＃中，您将简单地将接口类型用于参数

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

类型进入“与做一些特定事物的对象交谈”。上面定义的方法知道对对象的期望，它会在i Interface中实现所有内容，但是它不在乎它是哪种类型的对象，只有它遵守合同，这就是接口。

例如，您可能会熟悉计算器，并且可能在您的日子里使用了很多，但是大多数情况下它们都不同。另一方面，您知道标准计算器应该如何工作，因此即使您无法使用每个计算器所没有的特定功能，也可以使用它们。

这是界面的美丽。您可以编写一个代码，知道它会将对象传递给它，它可以期望某些行为。它不在乎一个hoot是什么样的对象，只是它支持所需的行为。

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

我们有一个用于Windows表单的定制翻译系统。该系统通过表单上的控件循环并翻译每个文本。该系统知道如何处理基本控件，例如控制型的型式控制，以及类似的基本内容，但是对于任何基本的东西，它都会降低。

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

1. 建立对我们的翻译系统的支持，以专门检测其正在使用的哪种控制类型，并翻译正确的位（维护）噩梦）
2. 将支持构建为基础类（不可能，因为所有控件都从不同的预定义类继承）
3. 添加接口支持

，因此我们做了NR。 3。我们所有的控件都实现了iLocalizable，这是一个界面，它为我们提供了一种方法，即将“本身”转换为翻译文本/规则容器的能力。因此，该表单不需要知道它发现了哪种控制，只能实现特定的接口，并且知道有一种可以调用以定位控件的方法。

Answer 17

界面的代码不是与Java无关，也没有其界面构造。< / strong>

这个概念在四本书的模式 /帮派中引起了人们的关注，但很可能在此之前就在附近。 概念肯定存在于Java存在之前。

这个 比原始意图。但是，这是我们在Java，C ++，C＃等中拥有公共和私人方法和属性的原因。

这意味着只需与对象或系统的公共接口进行交互。不用担心，甚至预料它在内部做什么。不必担心它是如何实施的。在面向对象的代码中，这就是为什么我们有公共方法和私有方法/属性的原因。我们打算使用公共方法，因为私人方法仅在同类中内部使用。他们构成了班级的实现，可以根据需要更改而无需更改公共接口。假设关于功能，每次用相同的参数调用它时，类上的方法将执行相同的操作，并具有相同的预期结果。它允许作者更改班级的工作方式，其实施方式，而无需破坏人们如何与之互动。

您可以在接口上编程，而不是不使用接口构造的实现。您可以将其编程到接口而不是C ++中的实现，而C ++没有接口构造。只要两个大型企业系统通过公共接口（合同）进行交互，而不是在系统内部的对象上调用方法，就可以更加牢固地集成。预期，在给定相同的输入参数的情况下，界面始终以相同的预期方式做出反应。如果实现到接口而不是实现。这个概念在许多地方起作用。

摇晃认为Java界面与“界面到界面而不是实现”的概念有任何关系的想法。他们可以帮助应用这个概念，但它们不是这个概念。

Answer 18

听起来您了解接口的工作原理，但不确定何时使用它们以及它们提供的优势。以下是何时有意义的一些示例：

// 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等。

大多数添加程序和插件系统都可以与Interfaces脱离接口。

另一个流行的用途是用于存储库模式。假设我想从不同来源加载邮政编码列表

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

，然后我可以创建一个XMLZIPCODEREPOSITOR，SQLZIPCODEREPOSITORITORITY，CSVZIPCODEREPOSITORITORITY等。对于我的Web应用程序，我经常在早期创建XML存储库，以便在SQL Datagabase之前创建XML存储库准备好了。准备好数据库后，我写了一个SQLRepository来替换XML版本。我的其余代码完全不变，因为它仅在接口上运行。

方法可以接受诸如：

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

Answer 19

那里有很多解释，但是要使它更简单。以 list 为例。一个人可以通过以下列表来实现以下列表：

1. 内部数组
2. 通过
3. 其他实现

构建到接口，例如 list 来实现 。您仅代码列表的定义或 list 实际上意味着什么。

您可以在内部使用任何类型的实现，表示数组实现。但是，假设您希望出于某种原因更改实现，说一个错误或性能。然后，您只需要更改声明 list＆lt; string＆gt; ls = new arraylist＆lt; string＆gt;（） to list＆lt; string＆gt; ls = new linkedlist＆lt; string＆gt;（）。

在代码中，其他任何地方都没有其他任何内容；因为其他所有内容都是基于 list 的定义。

Answer 20

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

我处理与运行医疗设备的服务器对话的客户端软件。我们正在开发此设备的新版本，该版本具有一些新组件，有时必须配置这些组件。新组件有两种类型，它们不同，但是它们也非常相似。基本上，我必须创建两个配置表单，两个列表类，两个类别。

我认为最好为每种控制类型创建一个抽象基类，该类型几乎可以容纳所有真实的逻辑，然后派生的类型来照顾两个组件之间的差异。但是，如果我不得不一直担心类型（嗯，它们可能会有，但是在每种方法中都会有一个“ if”语句或切换），基本类将无法对这些组件进行操作。

我为这些组件定义了一个简单的接口，所有基类都与此接口进行了交谈。现在，当我更改某些内容时，它几乎到处都可以“工作”，而且我没有代码重复。

Answer 21

如果您在Java进行编程，JDBC就是一个很好的例子。 JDBC定义了一组接口，但没有说明实现。您的应用程序可以用这组接口编写。从理论上讲，您选择了一些JDBC驱动程序，而您的应用程序只能使用。如果您发现有更快或“更好”或更便宜的JDBC驱动程序或出于任何原因，理论上您可以再次对您的属性文件进行重新配置，而无需对应用程序进行任何更改，则您的应用程序仍然可以正常工作。

Answer 22

我是这个问题的晚期，但我想在这里提到“界面的程序，而不是实现”行在GOF（四个）设计模式书中进行了一些很好的讨论。

它在p上说。 18：

程序到接口，而不是实现

不要将变量声明为特定混凝土类的实例。相反，仅对由抽象类定义的接口提交。您会发现这是本书设计模式的共同主题。

首先，它始于：

仅根据抽象类定义的接口来操纵对象有两个好处：

1. 客户仍然不知道其使用的特定对象，只要对象遵守客户端的界面。
2. 客户仍然不知道实现这些对象的类。客户只知道定义接口的抽象类。

因此，换句话说，请勿写它的类对于特定的类（或子类）的特定实现而言太具体了。相反，使用足够通用的名称编写该方法，例如 gissound（）或 move（），以便它们可以用于鸭子，狗甚至是汽车，然后您的类客户只能说 .givesound（），而不是考虑是否使用 quack（）或 bark（），甚至在发出要发送到对象的正确消息之前确定类型。

Answer 23

到界面的编程非常棒，它可以促进松散的耦合。正如@lassevk所述，控制反转是对此的极大用途。

此外，还要研究固体主体。 这是一个视频系列

它通过一个硬编码（强烈耦合示例）然后看起来在接口，最终发展到IOC/DI工具（ninject）

Answer 24

为了添加现有帖子，有时在开发人员同时在单独的组件上工作时，对接口进行编码有助于大型项目。您需要的只是预先定义接口并向它们编写代码，而其他开发人员将代码写入您正在实现的接口。

Answer 25

即使我们不依赖抽象的不同，它也可能有利于编程到接口。

界面的编程迫使我们使用对象的上下文适当子集。这是有帮助的，因为它是：

1. 防止我们做上下文不适当的事情，并
2. 让我们将来安全地改变实现。

例如，请考虑实现 friend 和员工接口的 person 类。

class Person implements AbstractEmployee, AbstractFriend {
}

在该人的生日的上下文中，我们将其编程到 friend 接口，以防止将其视为雇员。

function party() {
    const friend: Friend = new Person("Kathryn");
    friend.HaveFun();
}

在人的工作中，我们将编程为雇员接口，以防止工作场所的模糊界限。

function workplace() {
    const employee: Employee = new Person("Kathryn");
    employee.DoWork();
}

伟大的。我们在不同的情况下表现得很适当，我们的软件运行良好。

到未来，如果我们的业务改变与狗一起工作，我们可以很容易地更改软件。首先，我们创建一个 dog 类，同时实现 friend 和员工。然后，我们将 new Person（）将其安全地更改为 new Dog（）。即使两个函数都有数千行代码，该简单的编辑也会起作用，因为我们知道以下内容是正确的：

1. 函数 party 仅使用 friend> friend 的子集。
2. 函数工作场所仅使用员工 Person 的子集。
3. 类 dog 同时实现了 friend 和员工接口。

另一方面，如果 party 或工作场所是针对 person 进行编程 - 特定代码。从更改 dog 将要求我们梳理代码以消除任何 person - 特定的代码 dog> dog 不支持。

道德：与接口进行编程有助于我们的代码适当地表现并准备好进行更改。它还准备我们的代码取决于抽象，这带来了更多的优势。

Answer 26

如果我正在写新类游泳者添加功能 swim（），并且需要使用类SAIS SAID Dog 的对象，这狗类实现接口<代码>动物声明 swim> swim> 。

在层次结构的顶部（ Animal ），在底部（ dog ）时非常抽象，这是非常具体的。我对“与接口进行编程”的看法是，当我编写游泳器类时，我想针对界面编写代码动物对象。接口没有实现详细信息，因此使您的代码松散地耦合。

可以随时间更改实现详细信息，但是，由于您与接口而不是实现相互作用，它不会影响剩余的代码。您不在乎实现是什么样的...您所知道的是，将有一个可以实现界面的类。

Answer 27

先前的答案集中在编程上，以进行抽象，以扩展性和松散的耦合。虽然这些是非常重要的一点
可读性同样重要。可读性使他人（和您的未来自我）可以最少的精力理解代码。这就是为什么可读性利用抽象的原因。

从定义上讲，抽象比其实现更简单。抽象省略了细节，以传达事物的本质或目的，但仅此而已。
由于抽象更简单，因此与实施相比，我一次可以将更多的内容放在脑海中。

作为程序员（以任何语言），我始终在我的脑海中走动 list 的一般想法。特别是， list 允许随机访问，重复元素并维护顺序。当我看到这样的声明时： list mylist = new Arraylist（）我认为， cool ，这是 list 在（基本）我理解的方式；而且我不必再考虑它了。

另一方面，我脑海中没有携带 arrayList 的特定实现详细信息。因此，当我看到时， arrayList myList = new ArrayList（）。我认为， uh-oh ，必须以 list> list 接口不介绍的方式使用此 arraylist 。现在，我必须跟踪此 arrayList 的所有用法，以了解原因，因为否则我将无法完全理解此代码。当我发现此 arraylist do 符合 list> list 接口的100％用法时，它会变得更加令人困惑。然后我想知道...是否有一些代码依赖于 arraylist 实现详细信息？实例化的程序员是无能的吗？该应用程序是否在运行时以某种方式锁定到该特定实现中？我不明白的方式？

我现在对此应用程序感到困惑和不确定，而我们所谈论的只是一个简单的 list 。如果这是一个复杂的业务对象，忽略其界面怎么办？然后，我对业务领域的了解不足以了解代码的目的。

因此，即使我需要一个 list 严格在私有方法中（如果更改的情况下，什么都不会破坏其他应用程序，我可以轻松地找到/替换我的IDE中的所有用法）它仍然有利于编程进行抽象的可读性。因为抽象比实施细节更简单。您可以说，编程到抽象是遵守 kiss 原则的一种方式。

Answer 28

它也适合单位测试，您可以将自己的类（满足界面的要求）注入依赖于此的类

Answer 29

短篇小说：邮递员被要求回家后回家，并收到包含的封面（信件，文件，支票，礼品卡，申请，情书），并在其上写的地址交付。

假设没有掩护，请邮递员在回家后回家，收到所有的东西并交付给其他人，邮递员会感到困惑。

因此，更好地用封面包裹它（在我们的故事中是界面），然后他会做得很好。

现在，邮递员的工作是只接收和交付封面（他不会打扰封面中的内部）。

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

要创建界面，意味着您的组件可以轻松地融入其余代码

我给您一个例子。

您的飞机接口如下。

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

假设您在程序中的控制器类别中具有方法，例如

parkPlane(Airplane plane)

在

servicePlane(Airplane plane)

程序中实现。它不会中断您的代码。
我的意思是，只要它接受飞机的参数，就不必更改。

因为尽管实际类型， highflyr ，战斗机等，但它仍将接受任何

飞机

。飞机＆gt;飞机; //将占用所有飞机。

以下示例将清除您的理解。

---

您有一架实施它的战斗机，因此

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和其他Clasess来说，相同的东西：

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.
    }
}

几次使用飞机的控制器类，

假设您的控制器类是控制页面的，如下

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

现在 可能会使您的新飞机按照您想要的数量输入实例，并且您没有更改 Control Plane Plane 类的代码。

您可以添加一个实例...

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

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

Answer 30

因此，仅仅为了正确处理这个问题，接口的优点是我可以将方法的调用与任何特定类别分开。而是创建一个接口的实例，其中从我选择该界面的任何类中给出了实现。因此，我可以拥有许多类，这些类具有相似但略有不同的功能，在某些情况下（与界面的意图相关的情况）并不关心它是哪个对象。

例如，我可以有一个运动接口。一种使某物“移动”的方法和实现移动接口的任何对象（人，汽车，猫）都可以传递并被告知要移动。没有方法，每个都知道它的类型。