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

Question

Java 17 中添加了一个新接口

java.time.InstantSource

。如果该接口的所有实现都是

Clock

实现，那么该附加抽象的用例是什么？

Answer 1

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

问题

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

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

A

Supplier<Instant>

显然执行类似的功能，但它 缺乏可发现性和可理解性。另外，注射 通用接口往往会很痛苦。

用我的话来说：

Clock

类是作为当前时间的来源引入的。从概念上讲，当前时间的来源应该独立于时区。尽管如此，

Clock

还是有时区的。可能出于实用目的，以便您可以从中绘制各种日期时间对象：

LocalDate

、

ZonedDateTime

、

LocalTime

等。

所询问的

InstantSource

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

Clock

和

InstantSource

的目的之一是可测试性：使用它们，您可以控制运行测试时哪个时间被视为“当前时间”，当您想要可重复的测试时，这通常是必需的。

…如果无论如何该接口的所有实现都是 Clock 还实施吗？

我还没有检查 Java 17 附带的所有

InstantSource

实现是否都是

Clock

子类。即使是这种情况，（1）这不是重点，（2）没有人阻止你实现一个不是

InstantSource

的

Clock

。抽象是编程中的一个关键概念。如果您只想要

Instant

，那么您想要针对一个简单的界面进行编程，该界面只能给您

Instant

。

InstantSource

抽象了这样一个事实：您正在使用的对象也能够在其他上下文中扮演

Clock

的角色。

InstantSource

界面是应用备受推崇的 Façade 设计模式的学校示例（链接如下）。通过 Stephen Colebourne 对 bug 系统的描述，该界面使程序员在获得

Instant

s 的同时不再“捂着鼻子”。

链接

• 在 OpenJDK Bug 系统中添加 java.time.InstantSource。
维基百科上的
• 外观图案。

Answer 2

我最初请求将此接口添加到 ThreeTenExtra 也有一些额外的理由：https://github.com/ThreeTen/ Threeten-extra/issues/150