可选用途。

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别这样就行了。；)关于你的问题是。如果超载是没有选择的，是的。如果其他方法(子类，装饰，.)没有选择，是的。请不要！优势这样做可以减少null在您的代码库中，虽然它并没有消除它们。但这甚至不是重点。还有其他重要的好处：澄清意图使用Optional很清楚地表示变量是可选的。您的代码的任何读者或API的使用者都会受到打击，因为在访问该值之前，可能没有任何内容，并且需要进行检查。消除不确定性无Optional意义null目前还不清楚。它可以是一个国家的法律代表(见Map.get)或实现错误，如缺少或失败的初始化。持续使用Optional..在这里，已经发生了null表示bug的存在。(因为如果允许丢失值，则Optional会被使用)。)这使得调试空指针异常更容易，因为它的含义是null已经回答了。更多的空壳检查现在什么都不能null现在，这可以在任何地方执行。无论是使用注释、断言还是普通检查，您都不必考虑此参数或返回类型是否为空。它不能！缺点当然，没有银弹.。性能将值(特别是原语)封装到额外的实例中会降低性能。在紧密的循环中，这可能会变得明显，甚至更糟。注意，编译器可能能够在Optional在Java 10中价值类型可能会进一步减少或取消处罚。串行化Optional不可串行化但变通并不是太复杂。不变性由于Java中泛型类型的不变性，当将实际值类型推入泛型类型参数时，某些操作变得非常麻烦。给出了一个实例。这里(见“参数多态”).