为什么 Java 8 使用 null 时，Guava 的Optional 使用抽象类？

Question

当Java 8发布时，我期望发现它的Optional实现与Guava的基本相同。从用户的角度来看，它们几乎是相同的。但是Java 8的Optional在内部使用null来标记一个空的Optional，而不是使Optional抽象并有两个实现。除了 Java 8 的版本感觉不对（你只是通过隐藏你实际上仍在使用它们的事实来避免空值）之外，每次你想访问它时检查你的引用是否为空不是效率较低吗？而不是仅仅调用一个抽象方法？也许不是，但我想知道他们为什么选择这种方法。

Answer 1

也许 Google Guava 的开发者想要开发一种更接近函数世界的习惯用法：

\n\n

datatype \xe2\x80\x98a option = NONE | SOME of \xe2\x80\x98a\n

\n\n

在这种情况下，您可以使用模式匹配来检查类型选项实例的真实性质。

\n\n

case x of\n    NONE => //address null here\n  | SOME y => //do something with y here\n

\n\n

通过将 Option 声明为抽象类，Google Guava 遵循了这种方法，其中Option表示类型 ( )，和\'a option的子类表示该类型的特定实例 (和)。ofabsentSOME \'aNONE

\n\n

Option 的设计在 lambda 邮件列表中进行了深入讨论。用布莱恩·戈茨的话来说：

\n\n

\n

问题在于期望。这是一个经典的“盲人摸象”问题；对于不同的观点来说，所谓的“可选”有不同的“本质”，问题不在于每一个都无效，问题在于我们都使用相同的词来描述不同的概念（更多准确地说，假设 JDK 团队的目标与您居高临下地称为“熟悉该概念的人”的人的目标相同。

\n\n

JDK 中可选用途的设计范围很窄。目前的设计基本满足了这一点；它可能会以小的方式进行扩展，但目标不是创建一个选项 monad 或解决该选项 monad 想要解决的问题。（即使我们这样做了，结果仍然可能不令人满意；如果类库的其余部分没有遵循相同的单子 API 约定，没有更高级的泛型来抽象不同类型的单子，如果没有 <-\n 运算符形式的 Flatmap 语言支持，没有模式匹配等，将\nOptional 转换为 monad 的价值会大大降低。）鉴于这不是\n我们的目标，我们将在它停止根据我们的目标增加价值的地方停止。如果人们因为我们没有将 Java 转变为 Scala 或 Haskell 而感到不安，我很抱歉，但我们没有。

\n\n

纯粹从实际角度来看，围绕Optional的讨论已经超出了其设计预算几个数量级。我们仔细考虑了收到的大量意见，花了很多时间进行思考，并得出结论，当前的设计中心是当前的正确选择。肯定意味着善意的输入实际上正在迅速转变为拒绝服务攻击。我们可能会花费无尽的时间来来回争论这个问题，结果就不会有 JDK 8。我确信没有人想要这样。

\n\n

因此，让我们将对该主题的输入保留在当前实现的设计中心内，而不是试图说服我们更改设计中心。

\n

\n