这里有一个关于……的有趣用法(我认为)。测试。

我打算对我的一个项目进行大量测试，因此我构建断言;只是有些事我必须核实，有些事我不需要。

因此，我构建了一些东西来断言，并使用断言来验证它们，如下所示:

public final class NodeDescriptor<V>
{
    private final Optional<String> label;
    private final List<NodeDescriptor<V>> children;

    private NodeDescriptor(final Builder<V> builder)
    {
        label = Optional.fromNullable(builder.label);
        final ImmutableList.Builder<NodeDescriptor<V>> listBuilder
            = ImmutableList.builder();
        for (final Builder<V> element: builder.children)
            listBuilder.add(element.build());
        children = listBuilder.build();
    }

    public static <E> Builder<E> newBuilder()
    {
        return new Builder<E>();
    }

    public void verify(@Nonnull final Node<V> node)
    {
        final NodeAssert<V> nodeAssert = new NodeAssert<V>(node);
        nodeAssert.hasLabel(label);
    }

    public static final class Builder<V>
    {
        private String label;
        private final List<Builder<V>> children = Lists.newArrayList();

        private Builder()
        {
        }

        public Builder<V> withLabel(@Nonnull final String label)
        {
            this.label = Preconditions.checkNotNull(label);
            return this;
        }

        public Builder<V> withChildNode(@Nonnull final Builder<V> child)
        {
            Preconditions.checkNotNull(child);
            children.add(child);
            return this;
        }

        public NodeDescriptor<V> build()
        {
            return new NodeDescriptor<V>(this);
        }
    }
}

在NodeAssert类中，我这样做:

public final class NodeAssert<V>
    extends AbstractAssert<NodeAssert<V>, Node<V>>
{
    NodeAssert(final Node<V> actual)
    {
        super(Preconditions.checkNotNull(actual), NodeAssert.class);
    }

    private NodeAssert<V> hasLabel(final String label)
    {
        final String thisLabel = actual.getLabel();
        assertThat(thisLabel).overridingErrorMessage(
            "node's label is null! I didn't expect it to be"
        ).isNotNull();
        assertThat(thisLabel).overridingErrorMessage(
            "node's label is not what was expected!\n"
            + "Expected: '%s'\nActual  : '%s'\n", label, thisLabel
        ).isEqualTo(label);
        return this;
    }

    NodeAssert<V> hasLabel(@Nonnull final Optional<String> label)
    {
        return label.isPresent() ? hasLabel(label.get()) : this;
    }
}

这意味着断言只在我想检查标签时才会触发!

下面是一些你可以在Optional<T>实例上执行的方法:

地图 平面地图 或者其他 orElseThrow ifPresentOrElse 获取

以下是你可以在null上执行的所有方法:

(没有)

这实际上是一个苹果和橙子的比较:Optional<T>是一个对象的实际实例(除非它是null…但这可能是一个错误)，而null是一个中止的对象。对于null，您所能做的就是检查它实际上是否为空。所以如果你喜欢在对象上使用方法，Optional<T>适合你;如果您喜欢在特殊的字面量上进行分支，那么null是适合您的。

Null不构成。您不能简单地组合一个只能进行分支的值。但是Optional<T>确实作曲。

例如，您可以使用map创建任意长的“如果非空则应用此函数”链。或者，您可以有效地使用ifPresent创建一个命令代码块，如果可选值非空，则使用该可选值。或者你可以通过使用ifPresentOrElse来创建一个“if/else”，如果非空则使用非空可选参数，否则执行其他代码。

在这一点上，我们遇到了我认为语言的真正局限性:对于非常命令式的代码，你必须将它们包装在lambdas中，并将它们传递给方法:

    opt.ifPresentOrElse(
            string -> { // if present...
                // ...
            }, () -> { // or else...
                // ...
            }
    );

这对某些人来说可能不够好，就风格而言。

如果Optional<T>是一个可以进行模式匹配的代数数据类型(这显然是伪代码:

    match (opt) {
        Present(str) => {
            // ...
        }
        Empty =>{
            // ...
        }
    }

总之，总结一下:Optional<T>是一个非常健壮的空或现对象。Null只是一个哨兵值。

主观上忽视了原因

There seems to be a few people who effectively argue that efficiency should determine whether one should use Optional<T> or branch on the null sentinel value. That seems a bit like making hard and fast rules on when to make objects rather than primitives in the general case. I think it’s a bit ridiculous to use that as the starting point for this discussion when you’re already working in a language where it’s idiomatic to make objects left-and-right, top to bottom, all the time (in my opinion).

Optional与Iterator设计模式的不可修改实例具有类似的语义:

它可能引用也可能不引用对象(如isPresent()所给出的) 如果它确实引用了一个对象，则可以解除引用(使用get()) 但是它不能被提升到序列中的下一个位置(它没有next()方法)。

因此，在您以前可能考虑使用Java迭代器的情况下，请考虑返回或传递一个Optional。

我不认为Optional是可能返回空值的方法的一般替代品。

基本思想是:一个值的缺失并不意味着它在未来可能是可用的。它是findById(-1)和findById(67)之间的差值。

可选项对于调用者的主要信息是，他可能不指望给定的值，但它可能在某个时间可用。也许它会再次消失，然后再回来一次。这就像一个开/关开关。你可以“选择”打开或关闭灯。但是如果你没有灯可以打开，你就别无选择了。

所以我发现它太乱引入可选的地方，以前可能返回null。我仍然会使用null，但是只在一些受限的地方，比如树的根、惰性初始化和显式查找方法。

似乎Optional只有在Optional中的类型T是int、long、char等基本类型时才有用。对于“真正的”类，这对我来说没有意义，因为你可以使用空值。

我认为它是从这里(或从另一个类似的语言概念)。

Nullable < T >

在c#中，这个Nullable<T>很久以前就被引入到换行值类型中。

Optional的主要设计目标是为函数返回值提供一种方法，以指示没有返回值。请看这个讨论。这允许调用方继续一连串流畅的方法调用。

这与OP问题中的用例#1最接近。尽管，缺少值是比null更精确的表述，因为像IntStream。findFirst永远不能返回null。

对于用例#2，将一个可选参数传递给一个方法，这可以实现，但相当笨拙。假设您有一个方法，它接受一个字符串，后面跟着一个可选的第二个字符串。接受Optional作为第二个参数将导致如下代码:

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，但通常情况下，最好避免这样做。