是否应始终在 Java 中编码到接口 [已关闭]

总的来说，我同意其他答案：当你知道或预期变化和/或不同的实现时，使用接口，或者去测试。

但是，提前知道未来可能会发生什么变化并不总是那么容易，特别是如果你没有那么有经验的话。我认为这个问题的解决方案是重构：只要不需要它，就保持简单（=没有接口）。当需要时，只需进行“引入/提取接口”重构（几乎所有体面的IDE都支持）。

执行此操作时，仅提取调用方实际需要的那些方法。不要害怕提取多个单独的接口（如果不是所有提取的方法都是真正连贯的）。

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

编辑：根据Tarski的评论，我意识到了一个更重要的场景/对前面陈述的调整：
如果你提供一个外部API（用于其他[子]项目，或者真正“发布到野外”），那么在API中使用接口（除了简单的值类）几乎总是一个好主意。
如果您愿意，它将允许您在不干扰客户端代码的情况下更改impl。仅当您还必须更改界面时，您才会遇到问题。不破坏兼容性将是非常棘手的（如果不是不可能的话）。

当至少满足以下条件之一时，我使用它：

1）我想将不相关的模块/类彼此分离，并且我希望它能通过java包依赖关系来反映。

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

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

4）当我希望一个类是可测试的时，我会将其“链接点”设置为外部资源接口，以便我可以使用模拟实现。

5）不太常见：当我想有一个选项来限制对某个类的访问时。在这种情况下，我的方法返回一个接口而不是实际的类，所以调用方知道我不希望他对返回的值执行其他操作。