一个程序，从大的/宏观方面来说，就是一堆系统（数据库、消息队列、各应用Micro Service或单体App）通过定义的接口/协议进行通信；从小的/微观角度而言，就是对各个API/method的调用。
因此，系统的稳定/可用/质量 = 接口/协议/API的质量 + 调用方式 + 返回值处理方式。
我们的现状
看下我们日常都在干什么：
public class XyzService {
...
public BizBean biz(final String s, final Collection<? extends String> data) {
if (s == null)
throw new IllegalArgumentException("s can't be null");
if (data == null) {
throw new IllegalArgumentException("data can't be null");
}
final BazBean bazBean = anotherService.baz(s);
if (bazBean != null) {
...
} else {
...
}
return ...;
}
}
public class AnotherService {
...
public BazBean baz(final String s) {
if (s == null)
throw new IllegalArgumentException("s can't be null");
// your logic
return ...;
}
}
上面的代码我们日常可见的，也已习以为常：处处的防备 or 防御性编程。比较讽刺的是，即使这样，还是时不时的栽倒在NPE上。然后变本加厉，添加更多的防御代码 -_-
仔细想想，这真是我们想要的吗？我们是不是可以更优雅、少敲这些无聊代码吗？譬如这样：
@ParametersAreNonnullByDefault
public class XyzService {
...
public BizBean biz(final String s, @Nullable final Collection<? extends String> data) {
final Optional<BazBean> bazBean = anotherService.baz(s);
final SomeType v = bazBean.map(...).orElseGet(...);
return new BizBean(...)
}
}
@ParametersAreNonnullByDefault
public class AnotherService {
...
public Optional<BazBean> baz(final String s) {
// your logic
...
return Optional.ofNullable(...);
}
}
定义分析
大概解释下上面的定义：
@ParametersAreNonnullByDefault public class XyzService
声明这个类的所有的参数默认都是非null（这个主要是给IDE或者Findbugs/Checker Framework等用的，也可以内部/集体约定省掉这个注解）
public BizBean biz(...)
方法的返回值是有效的BizBean实例（非null）
biz(final String s)
非null的String s（参见class level的注解或者已经达成的内部共识）
biz(, @Nullable final ... data)
可为null的参数data。表明了方法可以优雅的处理data的null值
public Optional<BazBean> baz(...)
方法的返回值可能不存在，所以用Optional封装了下。调用者需要妥善处理不存在的情况（直接调用Optional.get()是危险操作）
通过上面的契约/注解，
-
作为方法调用方，知道了：
- 如何调用API（哪些参数可为null，哪些不可）
- 知道了如何处理返回值（非null的可直接处理，可为null的会返回Optional<T>）
-
对于方法的实现者，知道了：
- 可以直接使用非null参数
- 需要妥善处理可为null的参数
- 非null返回值必须返回有效值
- 可为null的返回值需要用Optional<T>封装后返回
优秀API定义
优秀的定义各有说辞，但一个：
- 定义清晰无歧义
- 专注于业务
的API，怎么说都可归于优秀的品质行列。
对照上面的示例代码，自己动手开始写类似的API可归纳为：
- 返回值
- 不可为null的，直接返回T
- 可为null的，返回Optional<T>
- 参数
- 默认都不可为null
- 可为null的，添加@Nullable注解
注意：其他设计优秀API的定义同样重要，这里只是侧重于相对小的一块讲解所以有所忽略。
一些例外
数组或集合类为返回值
在数组或集合类作为返回值时，通常返回空数组/或空集合代表不存在（而不是常规的通过返回Optional<T>表示可能值不存在）。
具体原因可直接看代码：
// 1.
public Optional<Collection<String>> m1(
return Optional.of(Collections.emptySet());
);
// 调用方对Optional返回值的处理
final Optional<Collection<String>> data = m1();
if (data.isPresent() && data.get().size() > 0) {
...
}
// 2.
public Collection<String> m2(
return Collections.emptySet();
);
// 调用方对空集合返回值的处理
final Collection<String> data = m2();
if (data.size() > 0) {
...
}
可以看到，对于集合/数组类返回值，很多时候我们还需要处理空集合/数组。和纯粹的返回空集合/数组相比，调用者还需要多一次Optional.ifPresent()调用。
所以，直接返回空集合/数组胜。
可为null的方法的参数不适合用Optional
既然Optional在返回值上面有上佳表现，那是否适用于参数呢？看个定义先：
public void m3(final Optional<String> s3);
// 可以空的时候调用
m3(Optional.empty());
public void m4(@Nullable final String s4);
// 可为null的时候调用
m4(null);
对于m3的s3这个参数定义，其值可以为：
- null （当然，根据集体约定，可以排除null可能）
- 非null，且有值
- 非null，没有值
从可为空和可为null的代码调用，m4(null)会更直观/简单。
虽然，Optional的方式会对方法的实现更有利，但评价API的设计，更多的时候需要从调用者角度出发。
所以，参数定义上，原则上不使用Optional。
Bean的字段是不是可以用Optional？
第一、Optional是非Serializable，所以需要序列化的Bean的字段是没法使用Optional的。
第二、哪怕你的Bean不需要序列化，Optional对于反射的不友好是不是也需要考虑下呢？
一个实际的做法（当然也是存在些争议，不过相比字段级上使用Optional小多了）：对于getter方法，可以使用Optional<T>作为返回值，以表明这个值可能不存在的语意。
希望这篇博文能对你有所帮助，喜欢的话点个赞吧！
参考资料
- Stackoverflow: Brian Goetz's answer for Should Java 8 getters return optional type?
- Java 8 Optional use cases
- The author of Java 8 In Action wrote Tired of Null Pointer Exceptions? Consider Using Java SE 8's Optional!
