Java的Optional能补充所有传统的if-null-else或if-not-null-else吗(java,optional,开发技术)

Java 添加的java.util.Optional非常的受欢迎，并为总是不能返回非null值的方法提供了更流畅的代码。很不幸的是，Optional已被滥用，一种滥用，甚至已被过度使用。当与直接使用相比null没有明显优势时，我偶尔会遇到使用Optional的代码。

当 Optional 与直接检查 null 相比没有任何优势，调用代码对它刚刚调用的方法的返回值使用Optional.ofNullable(T)时，可能会提示一个危险信号。如同所有的“危险信号”，这并不意味着将方法将返回值传递个Optional.ofNullable(T)（事实上，传递给期望 Optional 的 API 是必要的），但它的这种做法通常是用于不提供实际值，而不是直接使用返回值并检查它的是否为null。

在 Optional 可用之前，用于检查 null 方法返回的代码以及对 null 响应采取一种方式和对非 null 响应采取另一种方式的代码如下所示）。

对于这个基本条件，很少需要涉及Optional。下一个代码片段代表了我在开发人员尝试使用Optional替换显式空检测时偶尔看到的代码类型：

此代码中的范式与传统的null检查代码基本相同，但使用Optional.isEmpty()执行相同的检查。这种方法不会增加任何可读性或其他优势，但确实以额外的对象实例化和方法调用为代价。

上述用法的一个变体Optional是将其ifPresent(Consumer)方法与其isEmpty()方法结合使用，形成相同的基本逻辑，如果返回值存在则做一件事，如果返回值为空则做另一件事。这在以下代码中进行了演示。

这段代码看起来比直接检查 的返回值的传统方法要短一些null，但仍然以额外的对象实例化为代价，并且需要两次方法调用。此外，首先检查 Optional 是否存在然后立即检查它是否为空感觉有点奇怪。此外，如果需要执行的逻辑比将消息写到标准输出更复杂，这种方法就变得不那么实用了。