Java接口方法:每个类应该实现一个接口吗？

Question

我一直在用Java编写大学的几门课程,我有以下问题:

从方法论上接受每个类应该实现一个接口吗？不这样做被认为是不好的做法吗？你能描述一下使用接口不是一个好主意的情况吗？

编辑:就个人而言,我喜欢将Interfaces作为一种方法和习惯使用的概念,即使它并不明显有益.Eclipse自动创建了一个包含所有方法的类文件,因此它不会浪费任何时间.

Answer 1

如果您不打算使用它,则无需创建界面.

通常,在以下情况下需要接口:

单位测试和嘲笑+1.出于这个原因,我在几乎所有类中使用接口. (4认同)
@Philippe现代模拟框架可以模拟类. (4认同)
创建用于测试的模拟对象的框架，例如 JMock、EasyMock 或 Mockito。它们允许您测试与对象的交互，而无需实际测试该对象本身——可以将模拟配置为执行您的测试需要的任何内容（返回硬编码结果、抛出异常等）。 (2认同)

Answer 2

遵循YAGNI原则,如果您真的需要,类应该实现接口.否则你从中获得了什么？

编辑:接口提供了一种抽象.如果要在不同的实现(实现相同接口的许多类)之间进行交换,它们特别有用.如果它只是一个类,那么就没有收获.

Answer 3

每个类都实现了一个接口(即契约),因为它提供了非私有API.是否应该选择将接口单独表示为Java接口取决于实现是否是"变化的概念".

如果您完全确定只有一个合理的实现,那么就不需要接口.否则,接口将允许您在不更改客户端代码的情况下更改实现.

有些人会喊"YAGNI",假设您可以在以后发现新要求时完全控制更改代码.其他人会害怕他们需要改变不可更改的 - 一个已发布的API.

如果你没有实现一个接口(并使用某种工厂来创建对象),那么某些类型的更改将迫使你打破开闭原则.在某些情况下,这是商业上可接受的,而在其他情况下则不是.

你能描述一下使用接口不是一个好主意的情况吗？

在某些语言(例如C++,C#,但不是Java)中,如果您的类不包含虚拟方法,则可以获得性能优势.

在小程序或没有发布API的应用程序中,您可能会看到维护单独接口的成本很低.

如果由于分离接口和实现而导致复杂性显着增加,那么您可能不会将接口用作合同.接口降低了复杂性.从消费者的角度来看,组件成为履行合同条款的商品,而不是具有本身具有复杂实施细节的实体.

Answer 4

不,每个类都没有必要实现一个接口.仅在使代码更清晰且更易于编写时才使用接口.

如果您的程序目前不需要为给定的类提供多于1个实现,那么您不需要接口.例如,在我写的一个简单的国际象棋程序中,我只需要一种类型的Board对象.棋盘是棋盘棋盘.制作一个Board接口并实现它只需要更多的代码来编写和维护.

如果你最终需要它,那么切换到界面是如此容易.

Answer 5

没有必要为每个类创建一个接口。一些常见的原因包括模拟（不需要像 Mockito 这样的现代模拟框架）和依赖注入（例如 Spring，在现代实现中也不需要）。

如果需要，请创建一个接口，尤其是要正式记录公共接口。有几个漂亮的边缘情况（例如标记界面）。

值得一提的是，在最近的一个项目中，我们对所有东西都使用了接口（DI 和模拟都被列为原因），结果证明这是一种完全的浪费并增加了很多复杂性 - 添加接口同样容易实际上需要在极少数情况下模拟一些东西。最后，我相信有人会在某个周末进入并删除所有无关的接口。

我确实注意到最初转向 Java 的 C 程序员往往喜欢很多接口（“它就像头文件”）。当前版本的 Eclipse 支持这一点，允许通过控制单击导航生成一个弹出窗口，询问接口或实现。