与现有抽象类 Clock 相比，新接口 java.time.InstantSource 的主要目的是什么？

Question

在 Java 17 中添加了一个新接口 java.time.InstantSource。如果该接口的所有实现也是 Clock 实现，那么该额外抽象的用例是什么？

Answer 1

感谢 NoDataFound 提供评论中的链接（链接在此答案的底部重复）。 Stephen Colebourne（java.time 的原始开发者）的“错误”报告说：

问题

自从 Java 8 中首次添加 java.time 以来，很明显， 缺少一个概念——与时间无关的 Instant 的来源 区。简而言之，如果您唯一想要的是 Instant，那么 Clock 不是正确的 API，因为它迫使您考虑时区。

一个好的基于时间的代码的架构设计应该有一个 操作系统时钟的抽象（依赖关系）之间的分离 注入用于单元测试），以及链接到用户的时区 本土化。分别传递这两件事是关键。到 实现这一点，开发人员必须编写自己的 TimeSource 或 InstantSource 接口，或使用 Clock 并“保持其 鼻子”来忽略其中的时区。

Supplier<Instant> 显然执行类似的功能，但它 缺乏可发现性和可理解性。另外，注射 泛化的接口往往很痛苦。

用我的话来说：Clock 类是作为当前时间的来源引入的。从概念上讲，当前时间的来源应该与时区无关。 Clock 仍然有一个时区。可能出于实际目的，以便您可以从中绘制各种日期时间对象：LocalDate、ZonedDateTime、LocalTime 等。

询问的InstantSource接口实现了我刚才描述的时钟概念：一个独立于时区的当前时间的来源。当带有时区的时钟对于您的目的来说太重了。

Clock 和 InstantSource 的目的之一是可测试性：通过这些，您可以控制在运行测试时哪个时间被视为“当前时间”，当您想要可重复的测试时通常需要这样做。

...如果该接口的所有实现都是时钟 也有实现？

我没有检查 Java 17 附带的所有 InstantSource 实现是否都是 Clock 子类。即使是这种情况，（1）这不是重点，（2）没有人阻止你实现不是Clock的InstantSource。抽象是编程中的一个关键概念。如果你只想要Instants，那么你想针对一个只给你Instants 的简单接口编程。 InstantSource 抽象出这样一个事实，即您正在使用的对象也可以在其他一些上下文中扮演 Clock 的角色。 InstantSource 接口是应用备受推崇的 Façade 设计模式的学校示例（链接如下）。借助 Stephen Colebourne 来自 bug 系统的描述性文字，该界面让程序员在获取Instants 时无需“捂着鼻子”。

链接

• Add java.time.InstantSource 在 OpenJDK 错误系统中。
• Facade pattern 在维基百科上。