请使用复选框选择_使用可选是可选的

请使用复选框选择

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

最初由Google Guava引入并后来包含在Java 8软件包中的Optionial类只是包装可选对象的包装器。从包装对象存在或包装中没有对象的意义上讲，包装对象是可选的，在这种情况下，包装对象为空。那里没有太多魔法。包装代码Optional类坚持认为，包装的对象不是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 。这意味着您必须在方法中实现断言：

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

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

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

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

私人可选字段

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