当只有一个类会实现该接口时，我需要使用该接口吗？

#1 楼

严格来说，不，您可以，YAGNI适用。就是说，您花费在创建界面上的时间是最少的，特别是如果您拥有方便的代码生成工具来完成大部分工作。如果您不确定是否需要该接口，我会说最好是支持接口定义。

此外，使用接口即使对于单个类，也将为单元测试提供另一个模拟实现，而不是在生产中。关于这一点，Avner Shahar-Kashtan的答案有所扩展。

#2 楼

我会回答，是否需要一个接口并不取决于实现该接口的类数。接口是用于定义应用程序的多个子系统之间的合同的工具。因此真正重要的是如何将应用程序划分为子系统。无论有多少类实现它们，都应该有接口作为封装子系统的前端。

这是一个非常有用的经验法则：


如果如果使Foo类直接引用BarImpl类，则您将坚定地承诺每次更改Foo时都要更改BarImpl。基本上，您将它们视为分成两个类的一个代码单元。
如果使Foo引用接口Bar，那么您将致力于避免更改Foo时更改BarImpl。

如果在应用程序的关键点定义接口，则需要仔细考虑它们应该支持和不应该支持的方法，并清楚地注释接口以描述实现应如何表现（以及如何），您的应用程序将更容易理解，因为这些带注释的界面将提供某种形式的应用程序规范，即对应用程序行为的描述。这样可以更轻松地阅读代码（而不是询问“此代码到底要做什么”，您可以问“此代码如何完成其​​应该做什么”）。

在除了所有这些（或者实际上是因为它）之外，接口还促进了单独的编译。由于接口要比其实现更容易编译并且具有更少的依赖关系，因此，这意味着如果编写类Foo以使用接口Bar，则通常可以重新编译BarImpl，而无需重新编译Foo。在大型应用程序中，这可以节省大量时间。

#3 楼

指定接口以定义行为，即一组功能/方法的原型。实现接口的类型将实现该行为，因此，当您处理这种类型时，您会（部分地）知道其行为。

如果知道该行为，则无需定义接口。它定义的将仅使用一次。吻（保持简单，愚蠢）

#4 楼

从理论上讲，您不应该仅仅为了拥有一个接口而拥有一个接口，Yannis Rizos的答案暗示了进一步的复杂性：

编写单元测试并使用诸如Moq或FakeItEasy（以我最近使用过的两个命名），您隐式地创建了另一个实现该接口的类。搜索代码或进行静态分析可能会声称只有一个实现，但实际上存在内部模拟实现。每当您开始编写模拟时，您都会发现提取接口是有意义的。

但是，还有更多。在更多情况下，存在隐式接口实现。例如，使用.NET的WCF通信堆栈可生成远程服务的代理，该代理又可实现接口。

在干净的代码环境中，我同意这里的其余回答。但是，请注意可能使用接口的任何框架，模式或依赖项。

#5 楼

不，您不需要它们，我认为为每个类引用自动创建接口是一种反模式。

为所有内容制作Foo / FooImpl确实要花钱。 IDE可以免费创建接口/实现，但是在浏览代码时，foo.doSomething()上的F3 / F12会带来额外的认知负载，从而带您到接口签名，而不是所需的实际实现。另外，您有两个文件，而不是所有文件都杂乱无章。

因此，仅在实际需要某些文件时才应该这样做。

现在解决反对论点：

我需要依赖关系注入框架的接口

支持框架的接口是旧的。在Java中，接口以前是CGLIB之前的动态代理的要求。今天，您通常不需要它。它被认为是进步，对开发人员来说是福音，对您而言，EJB3，Spring等不再需要它们了。

我需要模拟进行单元测试

如果您编写自己的模型，模拟并有两个实际的实现，那么一个接口是合适的。如果您的代码库同时具有FooImpl和TestFoo，我们可能不会首先进行讨论。

但是，如果您使用的是Moq，EasyMock或Mockito之类的模拟框架，则可以模拟类，而您不需要接口。这类似于在可以分配方法的动态语言中设置foo.method = mockImplementation。

我们需要接口来遵循依赖倒置原则（DIP）

DIP表示您构建时要依赖合同（接口）而不是实现。但是一个类已经是一个契约和一个抽象。这就是public / private关键字的用途。在大学里，规范的例子就像是Matrix或Polynomial类-消费者拥有一个公共API来创建矩阵，添加矩阵等，但不允许关心矩阵是稀疏形式还是稠密形式。无需IMatrix或MatrixImpl即可证明这一点。

此外，DIP通常在每个类/方法调用级别上都过度应用，而不仅仅是在主要模块边界上。您过度使用DIP的迹象是您的界面和实现以锁定步长进行更改，因此您必须触摸两个文件才能进行更改，而不是一个。如果正确应用了DIP，则意味着您的界面不必经常更改。另外，另一个迹象是您的界面只有一个真正的使用者（它自己的应用程序）。如果您要构建用于在许多不同应用程序中使用的类库，则情况会不同。

这是Bob Martin叔叔关于模拟的观点的必然结果-您只需要在主要架构边界进行模拟。在Webapp中，HTTP和DB访问是主要的界限。两者之间的所有类/方法调用都不是。 DIP也是如此。

另请参见：


http://www.adam-bien.com/roller/abien/entry/service_s_new_serviceimpl
http：// martinfowler.com/bliki/InterfaceImplementationPair.html
https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
http://wrschneider.github.io/ 2015/07/27 / foo-fooimpl-pairs.html

#6 楼

看起来栅栏两侧的答案都可以总结为：


设计良好，并将接口放置在需要接口的地方。


正如我在回答Yanni的回答中所指出的那样，我认为您不可能对接口有一个严格的规定。根据定义，该规则必须灵活。我对接口的规则是，在创建API的任何地方都应使用接口。而且，应该在跨越一个责任域到另一个责任域的任何地方创建一个API。对于（一个非常人为的）示例，假设您正在构建一个Car类。在您的课程中，您肯定需要一个UI层。在此特定示例中，采用IginitionSwitch，SteeringWheel，GearShift，GasPedal和BrakePedal的形式。由于这辆车包含AutomaticTransmission，因此您不需要ClutchPedal。 （由于这是一辆糟糕的汽车，因此没有空调，收音机或座椅。事实上，地板也缺失了-您只需要挂在那个方向盘上，并希望最好就可以了！）

那么哪些类需要接口？答案可能是全部，也可能全都不是-取决于您的设计。

您可能会有一个类似于以下的界面：

Interface ICabin
    Event IgnitionSwitchTurnedOn()
    Event IgnitionSwitchTurnedOff()
    Event BrakePedalPositionChanged(int percent)
    Event GasPedalPositionChanged(int percent)
    Event GearShiftGearChanged(int gearNum)
    Event SteeringWheelTurned(float degree)
End Interface

那时，这些类的行为成为ICabin接口/ API的一部分。在此示例中，类（如果有的话）可能很简单，具有一些属性以及一个或两个函数。而且，您对设计的隐含说明是，这些类仅用于支持您所拥有的ICabin的任何具体实现，它们不能单独存在，或者在ICabin上下文之外毫无意义。

这是您不对私有成员进行单元测试的原因-它们仅用于支持公共API，因此应通过测试API来测试其行为。

因此，如果您的班级仅是为了支持另一个班级而存在，并且从概念上讲您认为它并不是真正拥有其自己的域，那么可以跳过该界面。但是，如果您的班级非常重要，以至于您认为班级已经足够长，可以拥有自己的领域，那就继续给它一个接口。


编辑：

经常（包括在此答案中），您会读到“域”，“依赖项”（经常与“注入”结合）之类的东西，这些对您开始编程时并不意味着什么（他们肯定没有这样做）。对我来说没有任何意义）。对于域，它的含义完全是这样：


行使主权或权威的领土；
主权或联邦的财产，或者
喜欢。也用于比喻。 [WordNet感2]
[1913 Webster]


在我的示例中-让我们考虑IgnitionSwitch。在肉类汽车中，点火开关负责：


验证（未识别）用户（他们需要正确的钥匙）
向启动器提供电流实际启动汽车
向点火系统提供电流，以便它可以继续运行
切断电流，使汽车停止。
取决于您的看法，大多数（全部）较新的汽车有一个开关，可以防止在变速器不在驻车挡位时从点火开关上拔下钥匙，因此这可能是其范畴的一部分。 （实际上，这意味着我需要重新考虑和重新设计系统...）

这些属性构成了IgnitionSwitch的领域，或者换句话说，它了解并负责。 />
IgnitionSwitch对GasPedal不承担任何责任。点火开关在任何方面都完全不了解油门踏板。它们都彼此完全独立地运行（尽管没有它们，一辆汽车将毫无价值！）。

如我最初所说，这取决于您的设计。您可以设计一个具有两个值的IgnitionSwitch：On（True）和Off（False）。或者，您可以设计它来验证为其提供的密钥以及许多其他操作。这是成为开发人员决定在哪里划清界限的难点，而且老实说，大多数情况下，这是完全相对的。但是，这些内容很重要-那是您的API所在的位置，因此也应该是您的接口所在的位置。

#7 楼

否（YAGNI），除非您打算使用此接口编写其他类的测试，并且这些测试将从模拟接口中受益。

#8 楼

来自MSDN：

接口更适合于您的应用程序需要许多可能不相关的对象类型来提供某些功能的情况。
接口比基类更灵活，因为您可以定义单个实现可以实现多个接口。
在不需要从基类继承实现的情况下，接口更好。
在不能使用类继承的情况下，接口非常有用。例如，结构不能从类继承，但是它们可以实现接口。

通常在单个类的情况下，不需要实现接口，但是考虑到项目的未来，正式定义类的必要行为可能很有用。

#9 楼

这里的所有答案都很好。实际上，大多数时候您不需要实现其他接口。但是在某些情况下，您可能仍要这样做。在某些情况下，我会这样做：

该类实现了另一个我不想公开的接口
桥接第三方代码的适配器类经常发生。

interface NameChangeListener { // Implemented by a lot of people
    void nameChanged(String name); 
} 

interface NameChangeCount { // Only implemented by my class
    int getCount();
}

class NameChangeCounter implements NameChangeListener, NameChangeCount {
    ...
}

class SomeUserInterface {
    private NameChangeCount currentCount; // Will never know that you can change the counter
}

该类使用一种特定的技术，该技术在与外部库进行交互时通常不应该泄漏槽
。即使只有一个实现，我也会使用一个接口来确保不引入与外部库的不必要的耦合。

interface SomeRepository { // Guarantee that the external library details won't leak trough
    ...
}

class OracleSomeRepository implements SomeRepository { 
    ... // Oracle prefix allow us to quickly know what is going on in this class
}

跨层通信
即使只有一个UI类实现了一个域类，它也可以在这些层之间实现更好的分隔，最重要的是，它可以避免循环依赖性。

package project.domain;

interface UserRequestSource {
    public UserRequest getLastRequest();
}

class UserBehaviorAnalyser {
    private UserRequestSource requestSource;
}

package project.ui;

class OrderCompleteDialog extends SomeUIClass implements project.domain.UserRequestSource {
    // UI concern, no need for my domain object to know about this method.
    public void displayLabelInErrorMode(); 

    // They most certainly need to know about *that* though
    public UserRequest getLastRequest();
}

仅一个子集该方法应该适用于大多数对象
大多数情况是在我对具体类有某种配置方法的情况下发生的

interface Sender {
    void sendMessage(Message message)
}

class PacketSender implements Sender {
    void sendMessage(Message message);
    void setPacketSize(int sizeInByte);
}

class Throttler { // This class need to have full access to the object
    private PacketSender sender;

    public useLowNetworkUsageMode() {
        sender.setPacketSize(LOW_PACKET_SIZE);
        sender.sendMessage(new NotifyLowNetworkUsageMessage());

        ... // Other details
    }
}

class MailOrder { // Not this one though
    private Sender sender;
}

所以最后我将接口用于我使用私有字段的原因相同：其他对象不应访问他们不应该访问的内容。如果遇到这种情况，即使只有一个类实现该接口，我也会引入一个接口。

#10 楼

要回答这个问题：不仅如此。

接口的一个重要方面是意图。

接口是“不包含数据的抽象类型，但公开了行为”-接口（计算）因此，如果这是类支持的一种行为或一组行为，则接口可能是正确的模式。但是，如果行为是类所体现的概念所固有的，则您可能根本不需要接口。

第一个要问的问题是您要代表的事物或过程的性质。然后继续以给定方式实现这种性质的实际原因。

#11 楼

自从您问了这个问题之后，我想您已经看到了隐藏多个实现的接口的好处。这可以通过依赖关系反转原理来体现。

但是，是否需要一个接口并不取决于其实现的数量。接口的真正作用是定义一个合同，该合同说明应提供什么服务而不是应如何实现。

一旦定义了合同，两个或多个团队就可以独立工作。假设您正在处理模块A，并且它依赖于模块B，那么在B上创建接口的事实使您可以继续工作而不必担心B的实现，因为所有细节都被接口隐藏了。因此，分布式编程成为可能。

尽管模块B仅具有其接口的一种实现，但该接口仍然是必需的。

最后，接口隐藏了实现细节它的用户。对接口进行编程有助于编写更多文档，因为必须定义合同，编写更多模块化软件，促进单元测试并加快开发速度。

#12 楼

接口确实很重要，但是请尝试控制所拥有的接口的数量。

创建接口的过程几乎一无所有，因此很容易以“切碎的意大利面条”代码结尾。我尊重阿扬德·拉希恩（Ayende Rahien）的大智慧，他在这个问题上发表了一些非常明智的话：

http://ayende.com/blog/153889/limit-your-abstractions-analyzing-a- ddd-application

这是他整个系列的第一篇文章，请继续阅读！

#13 楼

在这种情况下，您仍可能要引入接口的一个原因是要遵循“依赖倒置原则”。也就是说，使用该类的模块将依赖于它的抽象（即接口），而不是依赖于具体的实现。它将高级组件与低级组件分离。

#14 楼

没有真正的理由要做任何事情。接口是为了帮助您而不是输出程序。因此，即使该接口由一百万个类实现，也没有规则说您必须创建一个。您创建一个代码，以便当您或其他使用您代码的人想要更改时，可以渗入所有实现中。创建接口将在以后可能需要创建另一个实现该接口的类的所有将来的情况下为您提供帮助。

#15 楼

并非总是需要为类定义接口。

像值对象之类的简单对象没有多种实现。他们也不需要被嘲笑。可以单独测试实现，并且在测试依赖它们的其他类时，可以使用实际值对象。

请记住，创建接口是有代价的。它需要在实现过程中进行更新，需要一个额外的文件，并且某些IDE在缩放实现过程中会遇到问题，而不是接口。

所以我将只为更高级别的类定义接口，其中您需要实现的抽象。

请注意，使用类可以免费获得接口。除了实现之外，一个类还根据一组公共方法定义一个接口。该接口由所有派生类实现。它并不是严格意义上的接口，但可以完全相同的方式使用。因此，我认为没有必要重新创建以类名存在的接口。