Optional用法与争议点

素颜马尾好姑娘i 2024-04-01 15:33 84阅读 0赞

### 简介[\#][Link 1] ###

要说Java中什么异常最容易出现，我想NullPointerException一定当仁不让，为了解决这种null值判断问题，Java8中提供了一个新的工具类Optional，用于提示程序员注意null值，并在特定场景中简化代码逻辑。

比如下面一段取深层属性值的代码：

Order order = getOrderById(orderId);
    String userCode = "";
    if(order != null){
        if(order.getUser() != null){
            if(order.getUser().getUserCode() != null){
                userCode = order.getUser().getUserCode().toUpperCase();
            }
        }
    }

这种场景还比较常见，但深层嵌套的if判断，让代码阅读者压力倍增。

看看用Optional后的写法，如下：

Order order = getOrderById(orderId);
    String userCode = Optional.ofNullable(order)
        .map(Order::getUser)
        .map(User::getUserCode)
        .map(String::toUpperCase)
        .orElse("")

链式调用的写法，让代码可读性增强了不少，不用判断null，是因为Optional在内部已经做了null值判断了！那我们来看看Optional都有哪些用法吧。

### 创建Optional[\#][Link 2] ###

**ofNullable()方法**  
创建一个Optional，传入的值可以是null或不是null。

**of()方法**  
得到一个Optional，明确知道传入的值不是null时用这个，如果传null会报错NullPointerExcepiton。  
其实值不为null一般是没必要使用Optional的，这个应该是用于特殊场景，比如方法返回值必须是一个Optional。

**empty()方法**  
得到一个空的Optional，一般也用于返回值必须是Optional的场景。

### 判空[\#][Link 3] ###

**ifPresent()方法**  
判断是否有值，注意，这个方法虽然看起来挺好用的，但它不太应该是使用Optional时第一个使用的方法，如下：

if(opt.ifPresent())｛
        ...
    ｝
    if(obj != null) {
        ...
    }

这两个代码除了写法不一样，对于代码可读性方面没有根本区别！

### 取值[\#][Link 4] ###

**get()方法**  
获取Optional的值，当没有值时会抛出一个NoSuchElementException异常。

![294d6b09bc3e16545f3164c3d6383f0b.png][]

同样的，它也不太应该是使用Optional时的第一个使用的方法，因为抛NoSuchElementException与抛NullPointerException并没有太大区别。

**orElse方法**  
没有值时会返回指定的值。

String name = nameOpt.orElse("");

**orElseGet方法**  
同上，不过参数变成了一个提供默认值的lambda函数，这用在取指定值需要一定代价的场景，如下：

BigDecimal amount = amountOpt.orElseGet(() -> calcDefaultAmount());

**orElseThrow方法**  
没有值时抛出一个指定的异常，如下：

Optional<User> userOpt = getUser(userId);
    User user = userOpt.orElseThrow(() -> new NullPointerException("userId:" + userId));

可能会有人疑问，你还是抛出了一个NPE异常，和不使用Optional有啥区别？区别是这个NPE异常会告诉你哪个userId查不到数据，方便定位问题，而jvm抛出的NPE是没有这个信息的。

### 函数式处理[\#][Link 5] ###

**ifPresent(Consumer<? super T> consumer)方法**  
这个方法和`ifPresent()`方法不一样，这个方法代表如果Optional有值时，就执行传入的lambda函数，如下：

userOpt.ifPresent((user) -> System.out.printf("%s\n", user.toString()));

**filter方法**  
这个方法用于过滤Optional中的值，若Optional有值，且值满足过滤函数，则返回此Optional，否则返回空Optional。

![3d1d48385d6e6fbb83061153898eca8d.png][]

String name = nameOpt.filter(StringUtils::isNotBlank).orElse("");

**map方法**  
这个方法用于转换值，在最前面已经展示过了，若Optional有值，执行map中的lambda函数转换值，如下：

Optional还提供了一个flatMap方法，与map方法的区别是，传给flatMap的lambda函数，这个lambda函数的返回值需要是Optional。

### Optional争议点[\#][Link 6] ###

其实到底该不该用Optional，业界还是有不少争议的，一方面是Optional能强迫开发者处理null值，但另一方面是Optional又非常容易滥用，特别是一些开发者拿到Optional之后就直接调用`get()`或`ifPresent()`方法，这样几乎没解决任何问题，还加重了编码负担。

因此，我的建议是，在你不知道该不该使用Optional的场景，那就先别用。

下面是一些使用Optional的场景参考，如下：

1.  Optional一般用于返回值  
    Optional大多用于返回值，不推荐用在成员变量或方法参数中。
2.  Optional本身不判null  
    永远都不要给Optional赋值null，也不要判断Optional本身是否为null，这是因为Optional本来就是解决null的，再引入null就没意思了，这应该成为业界共识。
3.  集合不使用Optional  
    因为集合有`Collections.emptyList()`等更好的处理方法了，没必要再使用Optional。
4.  函数式处理值  
    从上面的用法介绍中就能发现，Optional提供了很多lambda函数式处理的方法，如filter、map等，这些是使用Optional时比较推荐使用的，因为Optional能帮你自动处理null值情况，避免NPE异常。
5.  多层属性获取  
    前面举过这个代码样例，我觉得这是Optional使用收益最明显的一个场景。
6.  不返回null胜过返回Optional  
    返回Optional给调用方，会强制调用方处理null情况，会给调用方增加一些的编码负担，特别是复用度很高的函数。  
    但如果调用方大多数情况下都不期望获取到null，那应该实现一个这样的方法，要么返回值，要么异常，如下：

/**
     * 查询订单，要么返回订单，要么异常
     */
    public Order getOrderByIdOrExcept(Long orderId){
        Order order = orderMapper.getOrderById(orderId);
        if(order == null){
            throw new BizException("根据单号" + orderId + "未查询到订单！");
        }
        return order;
    }
    
    /**
     * 查询订单，值可能为null
     */
    public Optional<Order> getOrderById(Long orderId){
        Order order = orderMapper.getOrderById(orderId);
        return Optional.ofNullable(order);
    }

由于后面处理代码依赖订单数据，获取不到订单数据，代码也没法往下走，所以在大多数情况下，选择使用`getOrderByIdOrExcept`方法更好，即避免了NPE，又避免了增加编码负担！

### 总结[\#][Link 7] ###

Optional能解决一些问题，但因为容易滥用而争议很大，因为Optional将null的处理交给调用方了，但大多数情况下，调用方也没办法处理这个null情况，还不如让JVM抛一个NPE异常中止执行，因为如果你用ifPresent的话，还更容易造成逻辑bug导致执行了不该执行的代码。

这和Java的受检查异常是一样的，强制要求调用方处理异常，但又有多少场景的异常是调用方可以处理的呢？这导致开发人员经常滥用catch，对异常处理一把梭了，最后发现catch后面还有一些本不该被执行的代码执行了。

[Link 1]: https://www.cnblogs.com/codelogs/p/16863888.html#%E7%AE%80%E4%BB%8B
[Link 2]: https://www.cnblogs.com/codelogs/p/16863888.html#%E5%88%9B%E5%BB%BAoptional
[Link 3]: https://www.cnblogs.com/codelogs/p/16863888.html#%E5%88%A4%E7%A9%BA
[Link 4]: https://www.cnblogs.com/codelogs/p/16863888.html#%E5%8F%96%E5%80%BC
[294d6b09bc3e16545f3164c3d6383f0b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/7b36e9534fa24fa0ab93d365c8c924b3.png
[Link 5]: https://www.cnblogs.com/codelogs/p/16863888.html#%E5%87%BD%E6%95%B0%E5%BC%8F%E5%A4%84%E7%90%86
[3d1d48385d6e6fbb83061153898eca8d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/c6f64df14d414b71bb80d3a0da5190d2.png
[Link 6]: https://www.cnblogs.com/codelogs/p/16863888.html#optional%E4%BA%89%E8%AE%AE%E7%82%B9
[Link 7]: https://www.cnblogs.com/codelogs/p/16863888.html#%E6%80%BB%E7%BB%93