java - 我应该对每个可能返回 null 的方法使用 Java8/Guava Optional 吗？

Question

Optional 用于表示可为空的对象，该类的一些用途包括

作为方法返回类型，作为返回 null 的替代方法
表示没有可用的值

区分“未知”(例如，不存在于 map 中)
和“已知没有值(value)”(存在于 map 中，具有值(value)
Optional.absent())

将可空引用包装在一个集合中以供存储
支持 null(尽管还有其他几种方法可以做到这一点)
应该先考虑)

对于第一种情况，我是否需要在所有可为空的返回方法中返回 Optional？

Answer 1

那么 Optional 有什么问题呢？

我们面临的问题是:JDK 8 Optional 对象会摆脱空引用吗？答案是否定的!因此，批评者立即质疑它的值(value):那么我们无法通过其他方式做到的有什么好处？

不像像 SML 或 Haskell 这样的函数式语言从来没有空引用的概念，在 Java 中我们不能简单地摆脱历史上存在的空引用。这将继续存在，并且可以说它们有其适当的用途(仅举一个例子: three-valued logic )。

我怀疑 Optional 类的意图是替换每一个可为空的引用，而是帮助创建更健壮的 API，其中只需读取方法的签名，我们就可以判断我们是否可以期待 optional 值，以及强制程序员相应地使用这个值。但最终，Optional 将只是另一个引用，并且受到语言中所有其他引用的相同弱点的影响(例如，您可以返回 null Optional)。很明显，Optional 不会挽救这一天。

应该如何使用这些 optional 对象或它们在 Java 中是否有值(value)一直是 heated debate 的问题。在项目 lambda 邮件列表中。我们从批评者那里听到有趣的论点，例如:

存在其他替代方案的事实(例如，像 IntelliJ 和 Eclipse IDE 这样的 IDES 支持一组 proprietary annotations 用于可空性的静态分析，JSR-305 带有@Nullable 和 @NonNull 等注释)。

有些人希望它能像 functional world 一样可用，这在 Java 中并不完全可行，因为该语言缺少 SML 或 Haskell 等函数式编程语言中存在的许多特性(例如模式匹配)。

其他人争论如何不可能retrofit preexisting code使用这个习语(例如 List.get(Object) 它将继续返回 null)。

并且有些人提示缺乏对 optional 值的语言支持会产生一个潜在的场景，其中 Optional 可能是 used inconsistently在 API 中，这会造成不兼容性，这很像我们将与 Java API 的其余部分所具有的不兼容性，这些 Java API 无法 retrofit 以使用新的 Optional 类。这几乎是你的问题。在支持 optional 类型的语言中 like in Ceylon或 like in Kotlin ，你甚至不会质疑这一点。

一个令人信服的论点是，如果程序员在一个 optional 对象中调用 get 方法，如果它是空的，它将引发一个 NoSuchElementException，这与我们在使用 null 时遇到的问题几乎相同，只是有一个不同的异常。

因此，似乎 Optional 的好处确实值得怀疑，并且可能仅限于提高可读性和强制执行公共(public)接口(interface)契约(Contract)。

我确实相信采用这种 Optional 函数式惯用语可能会使我们的代码更安全，减少空引用问题的提示，从而更健壮，更不容易出错。当然，这不是一个完美的解决方案，因为毕竟 Optional 引用也可能被错误地设置为 null 引用，但我希望程序员坚持不传递 null 引用的约定，在期望 optional 对象的地方，几乎就像我们今天认为一个好的做法是不要在需要集合或数组的地方传递空引用，在这些情况下，正确的做法是传递空数组或集合。这里的重点是，现在我们在 API 中有一个机制，我们可以使用它来明确表示对于给定的引用，我们可能没有分配给它的值，并且用户被 API 强制验证。

报价 Google Guava's article关于 optional 对象的使用:

“Besides the increase in readability that comes from giving null a name, the biggest advantage of Optional is its idiot-proof-ness. It forces you to actively think about the absent case if you want your program to compile at all, since you have to actively unwrap the Optional and address that case”.

所以，我想每个 API 设计者都可以选择他们想要在使用 Optional 方面走多远。

一些有影响力的开发人员如 Stephen Colebourne 和 Brian Goetz 最近发表了一些关于正确使用 optional 的有趣文章。我特别发现以下有用:

Should Java Getters Return Optional

Java SE 8 Optional, a pragmatic approach