Java边用边学：好用的Optional你用对了吗？

一个程序，从大的/宏观方面来说，就是一堆系统（数据库、消息队列、各应用Micro Service或单体App）通过定义的接口/协议进行通信；从小的/微观角度而言，就是对各个API/method的调用。

因此，系统的稳定/可用/质量 = 接口/协议/API的质量 + 调用方式 + 返回值处理方式。

我们的现状

看下我们日常都在干什么：

public class XyzService {
    ...
    public BizBean biz(final String s, final Collection 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 data) {
        final Optional bazBean = anotherService.baz(s);
        final SomeType v = bazBean.map(...).orElseGet(...);
        return new BizBean(...)
    }
}

@ParametersAreNonnullByDefault
public class AnotherService {
    ...
    public Optional 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 baz(...)

方法的返回值可能不存在，所以用Optional封装了下。调用者需要妥善处理不存在的情况（直接调用Optional.get()是危险操作）

通过上面的契约/注解，

• 作为方法调用方，知道了：

  • 如何调用API（哪些参数可为null，哪些不可）
  • 知道了如何处理返回值（非null的可直接处理，可为null的会返回Optional）

• 对于方法的实现者，知道了：

  • 可以直接使用非null参数
  • 需要妥善处理可为null的参数
  • 非null返回值必须返回有效值
  • 可为null的返回值需要用Optional封装后返回

优秀API定义

优秀的定义各有说辞，但一个：

• 定义清晰无歧义
• 专注于业务

的API，怎么说都可归于优秀的品质行列。

对照上面的示例代码，自己动手开始写类似的API可归纳为：

• 返回值
  • 不可为null的，直接返回T
  • 可为null的，返回Optional
• 参数
  • 默认都不可为null
  • 可为null的，添加@Nullable注解

注意：其他设计优秀API的定义同样重要，这里只是侧重于相对小的一块讲解所以有所忽略。

一些例外

数组或集合类为返回值

在数组或集合类作为返回值时，通常返回空数组/或空集合代表不存在（而不是常规的通过返回Optional表示可能值不存在）。

具体原因可直接看代码：

// 1.
public Optional> m1(
  return Optional.of(Collections.emptySet());
);
// 调用方对Optional返回值的处理
final Optional> data = m1();
if (data.isPresent() && data.get().size() > 0) {
    ...
}


// 2.
public Collection m2(
  return Collections.emptySet();
);
// 调用方对空集合返回值的处理
final Collection data = m2();
if (data.size() > 0) {
    ...
}

可以看到，对于集合/数组类返回值，很多时候我们还需要处理空集合/数组。和纯粹的返回空集合/数组相比，调用者还需要多一次Optional.ifPresent()调用。

所以，直接返回空集合/数组胜。

可为null的方法的参数不适合用Optional

既然Optional在返回值上面有上佳表现，那是否适用于参数呢？看个定义先：

public void m3(final Optional 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作为返回值，以表明这个值可能不存在的语意。

希望这篇博文能对你有所帮助，喜欢的话点个赞吧！

参考资料

• 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!