可选用途。

Question

可选用途。使用Java 8已经6个多月了，我对新的API更改非常满意。我仍然不自信的一个领域是什么时候使用Optional..我似乎在想要在任何地方使用它之间摇摆null在任何地方都没有。在很多情况下，我都可以使用它，我从来不确定它是否会增加好处(可读性/空安全性)，还是只会造成额外的开销。所以，我有几个例子，我会对社区的想法感兴趣Optional是有益的。1-当方法可以返回时，作为公共方法返回类型。null:public Optional<Foo> findFoo(String id);2-作为方法参数，当Param可能是null:public Foo doSomething(String id, Optional<Bar> barOptional);3-作为bean的可选成员：public class Book {   private List<Pages> pages;   private Optional<Index> index;}4英寸Collections:总的来说，我不认为：List<Optional<Foo>>添加任何东西-特别是因为我们可以使用filter()移除null价值等，但是有什么好的用途吗？Optional收藏？有我错过的案子吗？

Answer 1

主要点Optional是为返回值的函数提供一种方法，以指示没有返回值。看见这次讨论..这允许调用方继续进行一连串的FLUENT方法调用。

这个与用例最接近的匹配。#1在OP的问题上。虽然，无值是比零因为就像IntStream.findFirst永远不会返回NULL。

用例#2，将一个可选的参数传递给一个方法，这是可行的，但它相当笨拙。假设您有一个方法，它接受一个字符串，然后是一个可选的第二个字符串。接受Optional因为第二个Arg会产生这样的代码：

foo("bar", Optional.of("baz"));foo("bar", Optional.empty());

即使接受NULL也更好：

foo("bar", "baz");foo("bar", null);

最好的方法可能是有一个重载的方法，它接受单个字符串参数，并为第二个字符串提供一个默认值：

foo("bar", "baz");foo("bar");

这确实有其局限性，但它比上述任何一个都好得多。

用例#3和#4，有Optional在类字段或数据结构中，被认为是对API的误用。首先，它违背了Optional正如上面所说的。第二，它不增加任何价值。

有三种方法来处理Optional提供替代值、调用函数以提供替代值或抛出异常。如果要存储到字段中，则需要在初始化或赋值时执行此操作。如果您要将值添加到列表中，正如OP所提到的那样，您可以选择简单地不添加值，从而“扁平化”缺失的值。

我肯定有人会想出一些他们真正想要储存的Optional在字段或集合中，但是通常情况下，最好避免这样做。

Answer 2

这场比赛我迟到了，但不管值多少钱，我都想加2美分。他们违背了设计目标Optional，这是由斯图尔特·马克斯的回答，但我仍然相信它们的有效性(很明显)。

随时随地使用可选的

总体而言

我写了一整篇关于使用Optional但基本上是这样的：

• 在可行的情况下，设计类以避免可选性。
• 在所有其他情况下，默认情况应该是使用

  Optional

  而不是

  null

• 可能对以下情况作出例外：
• 局部变量
• 将值和参数返回到私有方法
• 性能关键代码块(没有猜测，请使用分析器)

前两个异常可以减少包装和解包装引用的开销。Optional..它们的选择使得NULL无法合法地将边界从一个实例传递到另一个实例。

请注意，这几乎永远不会允许Optional在集合中，它几乎和null别这样就行了。；)

关于你的问题

1. 是。
2. 如果超载是没有选择的，是的。
3. 如果其他方法(子类，装饰，.)没有选择，是的。
4. 请不要！

优势

这样做可以减少null在您的代码库中，虽然它并没有消除它们。但这甚至不是重点。还有其他重要的好处：

澄清意图

使用Optional很清楚地表示变量是可选的。您的代码的任何读者或API的使用者都会受到打击，因为在访问该值之前，可能没有任何内容，并且需要进行检查。

消除不确定性

无Optional意义null目前还不清楚。它可以是一个国家的法律代表(见Map.get)或实现错误，如缺少或失败的初始化。

持续使用Optional..在这里，已经发生了null表示bug的存在。(因为如果允许丢失值，则Optional会被使用)。)这使得调试空指针异常更容易，因为它的含义是null已经回答了。

更多的空壳检查

现在什么都不能null现在，这可以在任何地方执行。无论是使用注释、断言还是普通检查，您都不必考虑此参数或返回类型是否为空。它不能！

缺点

当然，没有银弹.。

性能

将值(特别是原语)封装到额外的实例中会降低性能。在紧密的循环中，这可能会变得明显，甚至更糟。

注意，编译器可能能够在Optional在Java 10中价值类型可能会进一步减少或取消处罚。

串行化

Optional不可串行化但变通并不是太复杂。

不变性

由于Java中泛型类型的不变性，当将实际值类型推入泛型类型参数时，某些操作变得非常麻烦。给出了一个实例。这里(见“参数多态”).