java实现可选形参_Java：可选的可选实现

java实现可选形参

类java.util.Optional被实现为单个不可变的具体类，该类在内部处理两种情况。一个有元素，一个没有元素。让Optional作为一个接口并让两个不同的实现代替实现该接口不是更好的选择吗？毕竟，这就是我们通常被教导要使用的一种面向对象的语言。

在本文中，我们将了解当前Optional实现的一些潜在参数。我们还将学习为什么以不同的方式实现Streams，从而使Streams可以从文件甚至数据库表中获取。

真正的可选实现

真正的java.util.Optional::get实现如下所示：

 public T get() { if (value == null ) { throw new NoSuchElementException( "No value present" ); } return value; }

可以看出，有两个代码路径。一种是值是null（没有元素，并且不会引发异常），另一种是值是其他值（返回值）。

可选可选实现

让我们假装我们将回到时光机中，并被要求再次实现Optional 。我认为我们中的许多人可能会提出一个初始解决方案，就像下面的解决方案（我将其命名为假设接口Option以便我们可以将其与“实际”接口进行区分）具有两个不同的实现（此处为EmptyOption和PresentOption ）：

 public interface Option<T> { T get(); boolean isPresent(); public <U> Option<U> map(Function<? super T, ? extends U> mapper); static <T> Option<T> empty() { return (Option<T>) EmptyOption.EMPTY; } (Option<T>) EmptyOption.EMPTY; } <T> Option<T> of(T value) { static <T> Option<T> of(T value) { return new PresentOption<>(value); } PresentOption<>(value); } <T> Option<T> ofNullable(T value) { static <T> Option<T> ofNullable(T value) { return value == null ? empty() : of(value); ? empty() : of(value); }  }  final class EmptyOption<T> implements Option<T> { static final EmptyOption<?> EMPTY = new EmptyOption<>(); private EmptyOption() {} @Override public T get() { throw new NoSuchElementException(); } NoSuchElementException(); } @Override public boolean isPresent() { return false ; } ; } @Override public <U> Option<U> map(Function<? super T, ? extends U> mapper) { requireNonNull(mapper); return (Option<U>) EMPTY; }  }  final class PresentOption<T> implements Option<T> { private final T value; PresentOption(T value) { this .value = requireNonNull(value); } .value = requireNonNull(value); } @Override public T get() { return value; } value; } @Override public boolean isPresent() { return true ; } ; } @Override public <U> Option<U> map(Function<? super T, ? extends U> mapper) { requireNonNull(mapper); return Option.ofNullable(mapper.apply(value)); }  }

为了简洁起见，仅示出了几种方法，但是原理保持不变：针对存在元素和不存在元素的情况的不同实现。这给出了更清晰的代码，也使任何人都可以实现可选选项。

分析

我有信心在构思Optional时，JDK团队已对这种解决方案进行了评估，并且我认为不选择该解决方案是明智的决定。 Optional主要目的是“包装”返回值，以防止NPE和返回原始空值的其他缺点。我还认为设计目标是使用Optional对性能的影响应该很小甚至可以忽略不计。

在下文中，我推测了一些论点，以选择以上所创造的当前的Optional实现。

剖面污染

JIT编译器按需编译Java字节码，以提高解释字节码的性能。

为了有效地做到这一点，JIT编译器能够收集每种已知方法的统计信息。每个方法都可以具有一个MethodData对象，该对象包含有关如何使用该方法的度量标准，并且一旦JVM认为该方法足够“温暖”（即在某种意义上已被充分调用），便会创建该对象。

创建和维护MethodData过程称为“分析”。

当调用之间使用的方法大不相同时，就会发生“配置文件污染”，包括但不限于提供交替的非null / null元素并调用不同的多态方法（例如，参数是类型T泛型，并且被调用的方法调用T::equals ）。 Java的基本功能是其动态调用方法的能力。因此，当调用Option::get时， EmptyOption::get或
最终调用PresentOption::get取决于调用时存在的实现。

一旦该方法被调用了10,000次，JIT编译器就会使用MethodData创建一个有效的已编译代码段，根据迄今为止收集的统计信息，该代码段将以最佳方式执行。

因此，如果元素始终存在（使用PresentOption ），并且牢记这一点编译代码，但随后突然出现EmptyOption ，则代码必须“退出”并采用慢得多的代码路径。

仅在最后一个类中使用Optional ，就不可能再有Optional方法的任何其他实现，因此，不会因不同的实现而造成配置文件污染。 JIT可以确定性地并合理地快速编译代码。

但是，等等，JVM不可能在启动时检查所有类并确定实际上只有两个实现类。
Option ，然后它可以解决整个问题？好吧，不。我们可以随时随意添加类，因此无法安全地枚举特定接口的所有可能实现。至少要等到我们有了Java中真正的密封类时，才能进行。

原料药污染

如果人们可以自由编写Optional自定义实现，那么与内置Optional相比，这些实现很可能会遭受设计缺陷/偏差。同样，人们可能会让他们自己的类型实现Optional接口，这增加了JIT编译器/分析器的负担，因此将诱使人们使用非预期的复合类型（例如Foo implements Bar, Optional<Bazz>) 。

另外， Optional现在是Java不可或缺的一部分，因此，可以使它与JDK本身一起有效发展，包括内联类和其他即将推出的Java新功能。