可选类型API

Java 8引入了Optional类。简而言之，不是返回null，而是检查null，而是返回Optional实例，该实例可以设置或不设置值。这样，您就不会因NullPointerException而失败。

我不会讨论Optional类型是否会完全消除NPE（不会）。相反，我将从另一个角度讨论问题-API设计。除了Java的Optional之外，我还将显示guava的Optional和scala的Option ，并进行比较。

正如Joshua Bloch所建议的，API应该尽可能小，但不能小。 API的概念权重应最小化，如果您想知道是否在API中包含某些内容，则应将其忽略。 API应该易于使用，并且难以滥用，并且理想情况下应该具有一个（或两个）主要使用模式。 Optional类型是必须做出所有这些选择的一个很好的例子。

这的默认用法是什么？您将获得一个可选类型，并且仅在设置了值的情况下才想执行一些代码。您显然可以通过将它与null进行比较来做到这一点，但是您常常会忘记这一点，而可选类型迫使您意识到此值实际上是可以设置的。第二个重要用例是，如果未设置默认值，则能够轻松提供默认值。

让我们首先从三个方面中最差的一个开始（我认为）– scala的Option 。最初，此类似乎为您提供了许多功能。但是，正如scala的正常做法一样，有很多不同的方法来使用类，但没有一种方法比其他方法更好。对我而言，这种情况下特别糟糕的决定是使Option （隐式）转换为Iterable 。对于非scala开发人员，让我们假设它是Iterable 。但是它只能有一个或零个元素。因此，为了实现我们的默认和最常见的用例，我们提供以下选项：

if (option.nonEmpty) {option.get.doSomething()}请使用命令式样式
使用.foreach – option.foreach(v => v.doSomething)
使用foreach循环（与上述不同）： for (value <- option) {value.doSomething()}
使用a来理解（用于…收益率）（与上述两项不同）
使用模式匹配- case Some与case None
使用地图，折叠，收集等–这使过程更进一步–不仅获得了价值，而且还对其应用了一些功能

因此，从可选类型的基本概念来看，我们有一个包含数十种方法的类。这个API在概念上很重要。没有明显的首选方法可以处理最常见的情况，实际上，许多scala开发人员首选的方法使用某种形式的foreach，当您知道最多有一个值时，这听起来有些怪异。

现在，让我们继续第二名候选人-Java 8 Optional 。您只有两种使用方法：使用if子句的命令式检查和ifPresent(function)方法，其中提供了一个在有值时处理代码的函数。您还可以使用几个重载方法来提供默认值（第二个用例）。我不喜欢的是map ， flatMap和filter方法。与上面的scala一样，它们很有用，但是可以将它们忽略（并且单独使用它们的用法，几乎不会增加冗长性），或者可以将它们简化为一个函数-map。它与flatMap有细微的差别，并且过滤单个元素并不是最有用的方法，此外，您可以使用map函数来实现。

我知道，到目前为止，您可能已经准备好（恼怒地）问您将如何编写非常简洁的代码，而无法折叠，收集，flatMap，过滤器。在使用给定的可选类型执行操作后返回另一个可选类型是第三个用例，这对于长方法很重要。它不如其他两个常见，因此应注意较少。理想情况下，一种方法就够了–所有其他子用例都可以在map函数本身中处理。

因此，我们找到了赢家–番石榴Optional 。它仅具有处理第一个用例的必要方法（因为它是为缺少一流功能的Java版本开发的）。上面的第二个和第三个用例具有尽可能少的方法（ or和transform(..) ）。轻量级API，可以用相同数量的代码实现几乎相同的事情。

实际上，针对主要用例采用功能性方法不一定是好方法–拥有Optional类型的意义在于无法在功能上起作用–关键是要意识到价值可能不存在。我并不是说要在scala和Java8中摆脱它，但也许可以重新考虑.isPresent()和.get() 。

最重要的是–很难设计API。就简单的事情而言，就算是可选类型，也有很多方面需要考虑主要和次要美国用例，以及是否需要便捷方法，或者它们为API添加了不必要的复杂性，并且可以用其他方法处理（不是一定更冗长）。

最后-在可能返回null的情况下使用可选类型-NPE易于调试和修复，但容易遗漏并且可能在错误的时刻发生。