java getter返回值_Java 8 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中提到过，但是大多数开发人员甚至都没有为他们的代码编写javadoc，并且没有多少人会在编写时检查javadoc . 因此，这会导致许多代码在使用它们之前始终检查空值，即使它们通常不能为空，因为它们已经在调用堆栈上重复验证了九到十次 .

我认为解决这个漏洞真的很渴望，因为很多人看到新的Optional类的目的是为了增加API的清晰度 . 这就是为什么人们会问像_588302这样的问题 . 不，他们可能不应该主要在Stream类中，这是函数式编程的核心 . (我没有仔细检查过，但Stream类可能是他们唯一使用的地方 . )

如果你计划在一些功能代码中使用getter，那么最好有一个标准的getter和一个返回Optional的第二个getter .

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

可选项是API缺陷的一个非常糟糕的解决方案，因为a)它们非常冗长，并且b)它们从未打算解决那个问题首先出现了 .

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

这改变了一切 .

至于你的getter，不要使用Optional . 并尝试设计您的类，以便没有成员可能为null . 并且可以尝试将Nullness Checker添加到您的项目中，并在需要时声明您的getter和setter参数@Nullable . 我只用新项目做了这件事 . 它可能会在现有项目中产生很多警告，这些项目使用了大量多余的null测试，因此改造可能很难 . 但它也会遇到很多错误 . 我喜欢它 . 因为它，我的代码更清晰，更可靠 .

(还有一种新的语言可以解决这个问题 . 编译为Java字节代码的Kotlin允许您在声明对象时指定对象是否为空 . 这是一种更清晰的方法 . )

Addendum to Original Post (version 2)

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

请记住，为函数式编程而设计的方法以及需要函数引用的方法将(并且应该)以两种形式编写，其中一种使用Optional . 例如， Optional.map() 和 Optional.flatMap() 都采用函数引用 . 第一个引用普通的getter，第二个引用一个返回Optional的引用 . 所以你're not doing anyone a favor by return an Optional where the value can'是空的 .

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