使用Optional来减少null检查

原创
2017/08/09 12:06
阅读数 1.4K

由来

平常我们使用null检查在项目中简直太常见了,从数据库中查询到的数据可能不存在返回null,service中处理中发现不存在返回一个null,在互相调用的时候每次都需要做(if obj != null)的判断,散落在程序中很难看。更难看的是当你遗漏了一个空指针判断,程序就会无情的给你抛出一个NPE让你知道谁才是老大。

假设我们有一个用户类User,用户可以有收货地址类Addr,收货地址中肯定会有省province属性啦,如果我们要获取用户的收货省,简单的来一个链式操作user.getAddr().getProvince(),这样操作可以么?

以往的null检查方式

用户在新注册之后可能是没有收货地址的,因此user.getAddr()返回null,再调用就会给你点颜色看看。因此我们必须要先判断null,然后才能决定是否可以调用getProvince方法

public String getUserConsigneeProvince(User user){
  if (user != null){
     Addr addr = user.getAddr();
     if (addr != null){
       return addr.getProvince();
     }
  }
  return null;  
}

或者使用防御式编程方式(以前我喜欢的编程方式),在检查到null后直接处理

public String getUserConsigneeProvince(User user){
  if (user == null){
    return null;
  }
  Addr addr = user.getAddr();
  if (addr == null){
    return null;
  }
  return addr.getProvince();
}

在这里我们也很鸡贼的返回了一个null来表示用户的收货省不存在,给以后的使用这个方法的人(当然也包括自己)挖了一个坑,如果直接返回给前端,那页面上就会有一个大大的null等着QA给你提bug吧。

1.8中对Null的处理

在Haskell中有一个Maybe类来处理可能的null,Scala中也提供了Option[T]来表示,Kotlin中使用在调用后加?来安全的处理返回值为null的情况。Java1.8借鉴了Haskell和Scala中方式,提供了一个Optional类来帮助程序员避免null检查。

设计哲学

我们看到在获取收货省的api中返回值直接是一个String,我们是不可能从这个返回值上面看出用户的收货省是否存在的,因此在设计时,对于可能不存在的值,我们选择返回一个Optional来表示你需要处理不存在的情况。

因此我们把返回值改写成Optional<String>

public Optional<String> getUserConsigneeProvince(User user){
  if (user == null){
    return Optional.empty();
  }
  Addr addr = user.getAddr();
  if (addr == null){
    return Optional.empty();
  }
  return Optional.of(addr.getProvince());
}

不过这并没有改善我们的内部处理,还是判断了null,因此我们先来看一下Optional的API,来来看一下用Optional如何简化我们的书写方式。

处理方式

API

Optional<T> Api:

名称 返回值 参数 说明
isPresent boolean void 如果不存在值则false,存在为true
ifPresent void Consumer 如果存在则调用Consumer消费值
map Function Optional<U> 对值做映射
flatMap Function Optional<U> 对值做扁平映射
orElse T T 存在返回包含的值,不存在就返回这里面的值
orElseGet T Supplier<T> 返回用supplier 生成的一个值
filter Predicate Optional<T> 过滤值
get T void 获取包装的值,不存在会抛出异常

可以看到API设计中使用到了函数式相关的东西,使得我们调用的时候可以使用lambda或者行为参数化的方式更方便的使用 在map和flatMap等API中隐含了null的判断,使得我们不用在应用中显式的去做null判断了。

一个参数的实践

接下来就是见证奇迹的时刻:

public Optional<String> getUserConsigneeProvince(User user){
  return Optional.ofNullable(user).map(User::getAddr).map(Addr::getProvince);
}

我们使用1行代码代替了6行,而且表达的更加清晰

当然如果这个API很多人使用,很难改变返回值的话我们可以使用orElse做值处理,如下:

public String getUserConsigneeProvince(User user){
  return Optional.ofNullable(user).map(User::getAddr).map(Addr::getProvince).orElse("");
}

get方法只有我们在确定值一定存在的情况下才能使用。

可以看到我们并未改变接口参数和返回值,但在内部处理上经过重写我们已经简化了非常多的代码,逻辑也变得清晰,更具有可读性。

为何可以如此写呢?Optional类其实是将null判断内化了,将null判断从用户手中接过来变成自己API的一部分,把用户从null判断的深渊中解放出来,只用关注自己的业务处理逻辑。

两个参数的处理

上面是一个参数的处理,如果我们有两个参数该怎么办呢。

假设有两个用户,我们需要判断一下他们是否是同一个省的,就使用上面已经提供的获取省的方法

public static boolean isSameProvince(User user1, User user2) {
    String user1Province = getUserConsigneeProvince(user1);
    String user2Province = getUserConsigneeProvince(user2);
    if (user1Province == null || user2Province == null) {
        return false;
    }
    if (user2Province.equals(user2Province)) {
        return true;
    }
    return false;
}

还好还好,只有一个if判断了null的情况,可是我们也用了9行才完成了这个简单的功能,我们其实最需要的equals这个判断,上面的三行null相关应该是需要避免的。 我们用Optional来改写一下,来感受下威力。

*public static boolean isSameProvince2(User user1, User user2) {
        return Optional.ofNullable(getUserConsigneeProvince(user1))
            .map(p -> Optional.ofNullable(getUserConsigneeProvince(user2))
                .filter(p2 -> p.equals(p2)))  
            .isPresent();
}

为了可读性我们写了4行,就算如此我们也减少了一半的代码,而且逻辑上更连贯,没有打断我们的可恶的null了。

总结

如上可以看出Optional在使用上带给我们的变化,让我们可以摆脱以往的null,用更加健康的调用方式来编写。也增加代码的可读性,逻辑上一气呵成。希望大家在平常多多使用。尽快远离恼人的null。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部