您应该始终用Java编写接口代码吗？

Question

我理解对接口进行编码的原理--将实现与接口分离，并允许接口的实现进行交换。

是否应该为我编写的每个类编写接口代码，或者这是否过分地扼杀了？我不想翻倍的源文件在一个项目，除非它是真正值得的。

，我可以使用哪些因素来决定是否按接口编码？

Answer 1

通常，我同意其他答案:当您知道或预期更改和/或不同的实现时使用接口，或者使用可测试性。

但要事先知道未来会发生什么变化并不总是容易的，尤其是如果你没有这么有经验的话。我认为这个问题的解决方案是重构:只要不需要就保持简单(=没有接口)。当需要时，只需做一个“导入/提取接口”重构(几乎所有体面的IDE都支持)。

当您这样做时，只提取调用方实际需要的方法。不要害怕提取多个独立的接口(如果不是所有提取的方法都是一致的)。

重构的一个驱动因素可能是测试:如果您不能轻松地用类测试某些东西，可以考虑引入一个/某个接口。这也将允许您使用模拟，这可能大大简化测试在许多情况下。

编辑：基于Tarski的评论，我意识到了一个更重要的场景/调整了前面的语句：

如果您提供了外部API (用于其他子项目，或真正将其“发布到野外”)，那么使用API中的接口(除了简单的值类)几乎总是一个好主意。

如果您愿意，它将允许您在不干扰客户端代码的情况下更改进程。只有当您还必须更改接口时，您才会有问题。不破坏兼容性将是非常棘手的(如果不是不可能)。

Answer 2

当下列至少有一项是正确的时候，我就使用它：

1)我希望将不相关的模块/类彼此解耦，我希望java包依赖关系能够反映它。

2)当解耦在构建依赖关系方面很重要时

3)当实现可能通过配置或在运行时动态更改(通常是由于某种设计模式)

4)当我希望一个类是可测试的时，我会让它的“链接点”指向外部资源接口，这样我就可以使用模拟实现。

5)不太常见:当我想有一个选项来限制对某个类的访问时。在本例中，我的方法返回一个接口而不是实际的类，因此调用方知道我不希望他对返回的值执行其他操作。

Answer 3

不，每个类都不应该有一个接口。这是过分的平方。

当您需要从所做的工作中抽象出所做的事情时，您可以使用一个接口，并且您可以确定实现可以改变。

看看java.util收集器API中的一个好例子。列表接口对于列表的一般概念来说是一个很好的抽象，但是您可以看到实现它的方法有很多: ArrayList、LinkedList等等。

更新:那么在这种情况下，您设计了一个具体的类，在您有客户端之后决定需要一个接口，然后通过添加一个接口来破坏您的客户端呢？是啊，就是这样。你怎么知道你不知道的？没有任何软件或方法能够解决这一问题。

对您来说，好消息是从具体类中提取接口对于您和您的客户端来说都是一个很容易实现的重构。IDEs经常处理这种事情。你和你的客户应该好好利用他们。

我要说的是，层，像服务和持久性一样，应该始终有接口。任何可以被代理的东西都应该有一个接口。如果您正在执行Spring，那么您想用一个方面来修饰的任何东西都应该有一个接口。

模型或值对象，如Person、Address或Phone，不应该有接口。不可变的值对象不应该有接口。

其余的归为灰色地带。用你最好的判断。