使用可选是可选的

在上周的“收藏中的可选内容”一文发表之后，我不禁要多讲一些关于同一只野兽的事情。更多细节。

最初由Google Guava引入并后来包含在Java 8软件包中的Optionial类只是包装可选对象的包装器。从包装对象存在或包装中没有对象的意义上讲，包装对象是可选的，在这种情况下，包装对象为空。那里没有太多魔法。包装代码（ 可选类）坚持包装的对象不是null 。毕竟null为null ，不是对象。对象永远不会为null 。只有对对象的引用可以为null 。

这些都是细微差别，细节；但重要的细节。毕竟，这些精细的细节是那些需要引入Optional的细节。一般的Java程序员看不到如此细微细节的重要性。他们认为Optional与包装对象本身的变量一样好，并假设变量也可以为null 。在某种程度上，它们是正确的。在自己的水平上。

这个级别表示好的代码是可以理解的，就是这样。运行银行，保险公司，起搏器和武器的大多数企业遗留代码都是在此级别上制定的。您无法做到这一点，只是希望自己有运气，而软件错误不会在“炸弹”中爆炸时选择您的房屋，银行账户或遗体（如果使用医疗设备）。您可以做的是理解问题并尽自己的一份力量来慢慢改善情况。除非我们所有人在那之前被消灭，否则这将需要几代人的时间。

“代码工作”和“可能理解”是软件的最基本要求。过去我们曾说过，如果软件能够运行，那么就可以了，对于维护而言，只要有两个能理解代码的“人”就够了：创建软件的编码者和创建编码的上帝。幸运的是，还有更高的水平。（我的意思是高于编码者。而不是高于上帝。）

下一个级别是“代码工作”和“易于理解（不是那么难）”。如果您必须调试代码并需要确定某些故障的根本原因，这一点很重要。 “代码工作”和“易于修改”再次成为新的阶梯。我看过容易理解的代码。代码正在运行。但是不同模块之间的依赖性是如此复杂，就像花边或传统的意大利面条一样。无论我想在此处更改某些内容以修复错误，还是在其他一些地方该程序开始失败。易于修改：该代码不是。

下一个级别是“代码工作”，“易于修改” 和 “很难创建错误的修改”。这意味着该代码提供了样式和内部数据结构以及API，维护人员将在一定程度上遵循它们，并将创建一个仍可正常工作，易于理解和修改的可修改工作代码。这是我们到达Optional的要点。

当方法返回Optional时 ，它表示它可能返回某些内容或什么都不返回。 Optional <Integer>可能返回一个Integer，但可能只返回一个空的Optional ，这意味着：没有我可以返回的Integer 。为什么比返回可能为null的Integer更好呢？

可选方法返回值

答案是，在返回Optional <Integer>的情况下，您不能：

integer = methodReturningIntegerOrNull();
otherInteger = integer +1;

导致NPE。你为什么这么做？因为您忘记检查了，JavaDoc在描述的末尾某处提到了这种可能性，当您进行编码时，该可能性在鼠标悬停在窗口上方不可见。如果是Optional <Integer> ，则必须执行以下操作：

optionalInteger = methodReturningOptionalInteger();
if( optionalInteger.isPresent() ){otherInteger = optionalInteger.get() +1;}

仍然有机会写：

optionalInteger = methodReturningOptionalInteger();
otherInteger = optionalInteger.get() +1;

但是在那种情况下，你应该得到你所得到的。

可选帮助您创建更多代码和更少文档。它提供了一种语义，以便以比可为空的值更难忽略的方式传递一些可选值。它说：我不信任您正确处理null ，因此给您一个包装的对象，因此您必须显式处理可选性。

如果您认为您可以轻松回答问题

需要Optional <Something>作为方法参数
具有一个私有字段可选。

是个好主意。

可选方法参数

有优点也有缺点。当论据说：

countFrom(Optional<Date> from, Date to);

显然，当缺少一个值时，可能会缺少from值，并且应该有一些特殊的默认语义。另一方面，调用方可以传递null以获得特殊行为。忽略错误的可选性，调用者传递null的可能性较小。即使参数是Optional ，实际传递的参数仍可以为null ，我希望在这种情况下该方法将抛出NPE。最后但并非最不重要的一点是，引入了Optional的另一个危险：调用者可以传递Optional，它包含一个非Date的对象。泛型可以在Java中轻松绕开，草率的编码器可能会传递错误的Optional 。这意味着您必须在方法中实现断言：

参数不为空，
参数是正确的类型。

还要记住，在方法返回值的情况下， Optional是说： 我不信任您正确处理null ，因此我给了您一个包装好的对象，因此您必须显式地处理可选性 。当您创建需要Optional作为参数的API时，此消息将是什么？ 请不要相信我！ 只给我可选的，因为即使我也不相信自己能够正确处理null值。 很奇怪… 另一方面，我相信您不会传递null或错误的类型。

我认为：在这种情况下，使用Optional不会比为API提供适当的文档提供更多的价值，并且不会强迫调用者表现得比它更好。另一方面，您将额外的代码放在自己的肩膀上。

给Optional提供您信任的代码，从不信任您的代码但不要求它的代码中接受它！相信自己！

私人可选字段

当您将本地私有字段声明为Optional时，您将迫使该类的开发人员更加注意该字段的可选功能。这样做的代价是额外的包装程序，可选的代码处理中的额外混乱情况。另一方面，没有太大的收获，因为您可以在检查所有要考虑字段空值的情况下获得扩展单元测试的相同质量级别。由于所有代码都由当前开发人员负责整个代码，因此Optional没有任何好处。就像您不信任自己一样。这是一个严重的问题，需要比Optional Java类提供的更多和不同的对待。