Java 8 getters 应该返回可选类型吗？

当然，人们会做他们想做的事。但是我们在添加此功能时确实有明确的意图，并且它不是通用的可能类型，就像许多人希望我们这样做一样。我们的目的是为库方法返回类型提供一种有限的机制，其中需要有一种清晰的方式来表示“无结果”，并且用于此类方法极有可能导致错误。null

例如，您可能永远不应该将其用于返回结果数组或结果列表的内容;而是返回空数组或列表。您几乎不应该将其用作某些内容的字段或方法参数。

我认为经常使用它作为getters的返回值肯定会被过度使用。

Optional没有错，应该避免它，它只是不是许多人希望的那样，因此我们相当担心热心过度使用的风险。

（公共服务公告：除非你能证明它永远不会是空的，否则永远不要调用;而是使用一种安全的方法，如 或 。回想起来，我们应该把类似的东西或更清楚地表明这是一种非常危险的方法，首先破坏了整个目的。吸取的教训。（更新：Java 10 具有 ，这在语义上等效于 ，但其名称更合适。Optional.getorElseifPresentgetgetOrElseThrowNoSuchElementExceptionOptionalOptional.orElseThrow()get()

在做了一些我自己的研究之后，我遇到了一些事情，这些事情可能会暗示什么时候是合适的。最权威的是以下引用甲骨文文章：

“重要的是要注意，Optional类的意图不是替换每个空引用。相反，其目的是帮助设计更易于理解的 API，以便只需读取方法的签名，就可以判断是否可以期望可选值。这迫使您主动解开 Optional 的包装，以处理缺少值的情况。- 厌倦了空指针异常？考虑使用 Java SE 8 的可选！

我还发现Java 8的这段摘录可选：如何使用它

“可选并不意味着在这些情况下使用，因为它不会给我们带来任何东西：

• 在域模型层中（不可序列化）
• 在 DTO 中（原因相同）
• 在方法的输入参数中
• 在构造函数参数中”

这似乎也提出了一些有效的观点。

我无法找到任何负面的内涵或危险信号来表明应该避免这种情况。我认为一般的想法是，如果它有帮助或提高了API的可用性，请使用它。Optional