Java 8 getter 是否应该返回可选类型？

当然，人们会为所欲为。但我们在添加此功能时确实有一个明确的意图，它 不是 是通用的 Maybe 类型，就像很多人希望我们这样做一样。我们的目的是为库方法返回类型提供一种有限的机制，其中需要一种明确的方式来表示“无结果”，而使用 null 来表示这种情况极有可能导致错误。

例如，您可能永远不应该将它用于返回结果数组或结果列表的东西；而是返回一个空数组或列表。您几乎不应该将它用作某物的字段或方法参数。

我认为经常使用它作为 getter 的返回值肯定会被过度使用。

Optional 应该避免它并没有错，它只是不是很多人希望的那样，因此我们相当担心过度使用的风险。

（公共服务公告：绝不调用 Optional.get，除非你能证明它永远不会为空；而是使用安全方法之一，如 orElse 或 ifPresent。回想起来，我们应该调用get 类似 getOrElseThrowNoSuchElementException 的东西，或者更清楚地表明这是一种高度危险的方法，它首先破坏了 Optional 的全部目的。吸取的教训。（更新：Java 10 有 Optional.orElseThrow()，它在语义上等价于 get()，但其名称更合适。））

---

在做了一些我自己的研究之后，我遇到了一些可能暗示什么时候合适的事情。最权威的是 Oracle 文章中的以下引用：

“重要的是要注意，Optional 类的目的不是替换每个空引用。相反，它的目的是帮助设计更易于理解的 API，以便通过阅读方法的签名，您可以判断您是否可以期望一个可选值。这会迫使您主动打开 Optional 以处理缺少值的情况。” - 厌倦了空指针异常？考虑使用 Java SE 8 的可选！

我还从 Java 8 Optional: How to use it 中找到了这段摘录

“可选并不意味着在这些上下文中使用，因为它不会给我们带来任何好处：在 DTO 中的域模型层（不可序列化）中（同样的原因）在构造函数参数中的方法的输入参数中”

这似乎也提出了一些有效的观点。

我找不到任何负面含义或危险信号来建议应该避免使用 Optional。我认为一般的想法是，如果它有帮助或提高 API 的可用性，请使用它。

---

我会说一般来说，将可选类型用于可以为空的返回值是一个好主意。但是，对于框架，我假设在使用依赖于 getter 和 setter 编码约定的框架（例如，Hibernate）时，用可选类型替换经典 getter 会导致很多麻烦。

---

将 Optional 添加到 Java 的原因是：

return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .findFirst()
    .getOrThrow(() -> new InternalError(...));

比这更干净：

Method matching =
    Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .getFirst();
if (matching == null)
  throw new InternalError("Enclosing method not found");
return matching;

我的观点是，Optional 是为了支持函数式编程而编写的，它同时被添加到 Java 中。 （该示例由 blog by Brian Goetz 提供。更好的示例可能使用 orElse() 方法，因为此代码无论如何都会引发异常，但您明白了。）

但是现在，人们出于非常不同的原因使用 Optional。他们正在使用它来解决语言设计中的缺陷。缺陷在于：无法指定 API 的哪些参数和返回值允许为空。它可能在 javadocs 中被提及，但大多数开发人员甚至不会为他们的代码编写 javadocs，而且很少有人会在编写时检查 javadocs。所以这导致很多代码在使用它们之前总是检查空值，即使它们通常不可能为空，因为它们已经在调用堆栈上重复验证了九到十次。

我认为解决这个缺陷真的很迫切，因为很多看到新 Optional 类的人都认为它的目的是增加 API 的清晰度。这就是为什么人们会问诸如“getter 应该返回 Optionals 吗？”之类的问题。不，他们可能不应该，除非您希望 getter 用于函数式编程，这不太可能。事实上，如果你看Java API中Optional的使用情况，主要是在Stream类中，它们是函数式编程的核心。 （我没有仔细检查过，但 Stream 类可能是它们唯一使用的地方。）

如果您确实计划在一些功能代码中使用 getter，那么拥有一个标准 getter 和另一个返回 Optional 的 getter 可能是个好主意。

哦，如果你需要你的类是可序列化的，你绝对不应该使用 Optional。

选项对于 API 缺陷来说是一个非常糟糕的解决方案，因为 a）它们非常冗长，并且 b）它们从一开始就没有打算解决这个问题。

API 缺陷的一个更好的解决方案是 Nullness Checker。这是一个注释处理器，允许您通过使用@Nullable 注释来指定允许哪些参数和返回值为空。这样，编译器可以扫描代码并确定是否将实际上可以为 null 的值传递给不允许为 null 的值。默认情况下，它假定任何内容都不允许为空，除非它被注释。这样，您就不必担心空值。将空值传递给参数将导致编译器错误。测试不能为 null 的对象会产生编译器警告。这样做的效果是将 NullPointerException 从运行时错误更改为编译时错误。

这改变了一切。

至于你的吸气剂，不要使用 Optional。并尝试设计您的类，使所有成员都不可能为空。也许尝试将 Nullness Checker 添加到您的项目中，并在需要时声明您的 getter 和 setter 参数@Nullable。我只在新项目中这样做过。它可能会在现有项目中产生很多警告，其中包含大量多余的 null 测试，因此可能很难进行改造。但它也会捕获很多错误。我喜欢它。因为它，我的代码更干净、更可靠。

（还有一种新的语言可以解决这个问题。编译为 Java 字节码的 Kotlin 允许您在声明对象时指定它是否可以为空。这是一种更简洁的方法。）

原始帖子的附录（第 2 版）

经过深思熟虑，我不情愿地得出结论，在一个条件下返回 Optional 是可以接受的：检索到的值实际上可能为 null。我见过很多代码，人们经常从不可能返回 null 的 getter 中返回 Optional。我认为这是一种非常糟糕的编码实践，只会增加代码的复杂性，从而更容易出现错误。但是，当返回值实际上可能为 null 时，请继续将其包装在 Optional 中。

请记住，为函数式编程而设计并且需要函数引用的方法将（并且应该）以两种形式编写，其中一种使用 Optional。例如，Optional.map() 和 Optional.flatMap() 都采用函数引用。第一个引用一个普通的 getter，第二个引用一个返回 Optional 的引用。因此，通过返回值不能为空的 Optional，您不会帮任何人忙。

说了这么多，我仍然认为 Nullness Checker 使用的方法是处理空值的最佳方法，因为它们将 NullPointerExceptions 从运行时错误转变为编译时错误。

---

如果您正在使用理解 Optional 的现代序列化程序和其他框架，那么我发现这些指南在编写 Entity bean 和域层时效果很好：

如果序列化层（通常是 DB）允许表 FOO 中 BAR 列中的单元格为空值，则 getter Foo.getBar() 可以返回 Optional 向开发人员指示该值可能合理地预期为空，并且它们应该处理这个。如果 DB 保证该值不会为 null，则 getter 不应将其包装在 Optional 中。 Foo.bar 应该是私有的而不是可选的。如果它是私有的，那么它真的没有理由是可选的。 setter Foo.setBar(String bar) 应该采用 bar 的类型而不是 Optional。如果可以使用 null 参数，则在 JavaDoc 注释中说明这一点。如果不能使用 null 一个 IllegalArgumentException 或一些适当的业务逻辑，恕我直言，更合适。构造函数不需要可选参数（原因类似于第 3 点）。通常我只在构造函数中包含在序列化数据库中必须为非空的参数。

为了使上述更有效，您可能需要编辑 IDE 模板以生成 getter 和 toString()、equals(Obj o) 等的相应模板，或者直接为这些使用字段（大多数 IDE 生成器已经处理空值）。

---

您必须记住，经常被引用的建议来自那些在 Java 之外几乎没有经验的人，他们对选项类型或函数式编程几乎没有经验。

所以带着一粒盐吃。相反，让我们从“良好实践”的角度来看它：

良好的实践不仅意味着问“我们如何编写新代码？”，还意味着“现有代码会发生什么？”。

在 Optional 的情况下，我的环境找到了一个很好且易于理解的答案：

Optional 是强制性的，以指示记录中的可选值：record Pet(String name, Optional Breed, Optional dateOfBirth)

这意味着现有代码按原样是好的，但使用 record 的代码（即“新代码”）会导致围绕它的 Optional 广泛采用。

结果在可读性和可靠性方面取得了圆满成功。停止使用 null。

---