关于null:匠人手法-优雅的处理空值

36次阅读

共计 7345 个字符，预计需要花费 19 分钟才能阅读完成。

我的公众号：MarkerHub，Java 网站：https://markerhub.com

更多精选文章请点击：Java 笔记大全.md

西格玛的博客

http://lrwinx.github.io/

在笔者几年的开发教训中，常常看到我的项目中存在到处空值判断的状况，这些判断，会让人感觉摸不这脉络，它的呈现很有可能和以后的业务逻辑并没有关系。但它会让你很头疼。

有时候，更可怕的是零碎因为这些空值的状况，会抛出空指针异样，导致业务零碎产生问题。

此篇文章，我总结了几种对于空值的解决手法，心愿对读者有帮忙。

[](# 场景 “ 场景 ”) 场景

存在一个 UserSearchService 用来提供用户查问的性能:

public interface UserSearchService{List<User> listUser();

  User get(Integer id);
}

[](# 问题现场 “ 问题现场 ”) 问题现场

对于面向对象语言来讲，形象层级特地的重要。尤其是对接口的形象，它在设计和开发中占很大的比重，咱们在开发时心愿尽量面向接口编程。
对于以上形容的接口办法来看，大略能够推断出可能它蕴含了以下两个含意:

  1. listUser(): 查问用户列表
  2. get(Integer id): 查问单个用户

在所有的开发中，XP 推崇的 TDD 模式能够很好的疏导咱们对接口的定义，所以咱们将 TDD 作为开发代码的”推动者”。
对于以上的接口，当咱们应用 TDD 进行测试用例后行时，发现了潜在的问题：

  1. listUser() 如果没有数据，那它是返回空集合还是 null 呢？
  2. get(Integer id) 如果没有这个对象，是抛异样还是返回 null 呢？

[](# 深刻 listUser 钻研 “ 深刻 listUser 钻研 ”) 深刻 listUser 钻研

咱们先来探讨 

listUser()

这个接口，我常常看到如下实现:

public List<User> listUser(){List<User> userList = userListRepostity.selectByExample(new UserExample());
    if(CollectionUtils.isEmpty(userList)){//spring util 工具类
      return null;
    }
    return userList;
}

这段代码返回是 null, 从我多年的开发教训来讲，对于汇合这样返回值，最好不要返回 null，因为如果返回了 null，会给调用者带来很多麻烦。你将会把这种调用危险交给调用者来管制。
如果调用者是一个审慎的人，他会进行是否为 null 的条件判断。如果他并非审慎，或者他是一个面向接口编程的狂热分子 (当然，面向接口编程是正确的方向)，他会依照本人的了解去调用接口，而不进行是否为 null 的条件判断，如果这样的话，是十分危险的，它很有可能呈现空指针异样！
依据墨菲定律来判断:“很有可能呈现的问题，在未来肯定会呈现!”

基于此，咱们将它进行优化:

public List<User> listUser(){List<User> userList = userListRepostity.selectByExample(new UserExample());
    if(CollectionUtils.isEmpty(userList)){return Lists.newArrayList();//guava 类库提供的形式
    }
    return userList;
}

对于接口 (List listUser())，它肯定会返回 List，即便没有数据，它依然会返回 List（汇合中没有任何元素）;
通过以上的批改，咱们胜利的防止了有可能产生的空指针异样，这样的写法更平安！

[](# 深入研究 get 办法 “ 深入研究 get 办法 ”) 深入研究 get 办法

对于接口 

User get(Integer id)

你能看到的景象是，我给出 id，它肯定会给我返回 User. 但事实真的很有可能不是这样的。

我看到过的实现:

public User get(Integer id){return userRepository.selectByPrimaryKey(id);// 从数据库中通过 id 间接获取实体对象
}

置信很多人也都会这样写。
通过代码的时候得悉它的返回值很有可能是 null! 但咱们通过的接口是分辨不进去的!
这个是个十分危险的事件。尤其对于调用者来说！

我给出的倡议是，须要在接口明明时补充文档, 比方对于异样的阐明, 应用注解 @exception:

public interface UserSearchService{

  /**
   * 依据用户 id 获取用户信息
   * @param id 用户 id
   * @return 用户实体
   * @exception UserNotFoundException
   */
  User get(Integer id);

}

咱们把接口定义加上了阐明之后，调用者会看到，如果调用此接口，很有可能抛出“UserNotFoundException(找不到用户)”这样的异样。

这种形式能够在调用者调用接口的时候看到接口的定义，然而，这种形式是”弱提醒”的！
如果调用者疏忽了正文，有可能就对业务零碎产生了危险，这个危险有可能导致一个亿！

除了以上这种”弱提醒”的形式，还有一种形式是，返回值是有可能为空的。那要怎么办呢？
我认为咱们须要减少一个接口，用来形容这种场景.
引入 jdk8 的 Optional, 或者应用 guava 的 Optional. 看如下定义:

public interface UserSearchService{

  /**
   * 依据用户 id 获取用户信息
   * @param id 用户 id
   * @return 用户实体, 此实体有可能是缺省值
   */
  Optional<User> getOptional(Integer id);
}

Optional 有两个含意: 存在 or 缺省。

那么通过浏览接口 getOptional()，咱们能够很快的理解返回值的用意，这个其实是咱们想看到的，它去除了二义性。

它的实现能够写成:

public Optional<User> getOptional(Integer id){return Optional.ofNullable(userRepository.selectByPrimaryKey(id));
}

[](# 深刻入参 “ 深刻入参 ”) 深刻入参

通过上述的所有接口的形容，你能确定入参 id 肯定是必传的吗？我感觉答案应该是：不能确定。除非接口的文档正文上加以阐明。

那如何束缚入参呢?

我给大家举荐两种形式：

  1. 强制束缚
  2. 文档性束缚（弱提醒）
  3. 强制束缚，咱们能够通过 jsr 303 进行严格的束缚申明:
public interface UserSearchService{
  /**
   * 依据用户 id 获取用户信息
   * @param id 用户 id
   * @return 用户实体
   * @exception UserNotFoundException
   */
  User get(@NotNull Integer id);

  /**
   * 依据用户 id 获取用户信息
   * @param id 用户 id
   * @return 用户实体, 此实体有可能是缺省值
   */
  Optional<User> getOptional(@NotNull Integer id);
}

当然，这样写，要配合 AOP 的操作进行验证，但让 spring 曾经提供了很好的集成计划，在此我就不在赘述了。

  1. 文档性束缚

在很多时候，咱们会遇到遗留代码，对于遗留代码，整体性革新的可能性很小。
咱们更心愿通过浏览接口的实现，来进行接口的阐明。
jsr 305 标准，给了咱们一个形容接口入参的一个形式 (须要引入库 com.google.code.findbugs:jsr305):

能够应用注解: @Nullable @Nonnull @CheckForNull 进行接口阐明。
比方:

public interface UserSearchService{
  /**
   * 依据用户 id 获取用户信息
   * @param id 用户 id
   * @return 用户实体
   * @exception UserNotFoundException
   */
  @CheckForNull
  User get(@NonNull Integer id);

  /**
   * 依据用户 id 获取用户信息
   * @param id 用户 id
   * @return 用户实体, 此实体有可能是缺省值
   */
  Optional<User> getOptional(@NonNull Integer id);
}

[](# 小结 “ 小结 ”) 小结

通过 空集合返回值, Optional,jsr 303，jsr 305 这几种形式，能够让咱们的代码可读性更强，出错率更低！

  1. 空集合返回值：如果有汇合这样返回值时，除非真的有压服本人的理由，否则，肯定要返回空集合，而不是 null
  2. Optional: 如果你的代码是 jdk8，就引入它！如果不是，则应用 Guava 的 Optional, 或者降级 jdk 版本！它很大水平的能减少了接口的可读性！
  3. jsr 303: 如果新的我的项目正在开发，不防加上这个试试！肯定有一种特地爽的感觉!
  4. jsr 305: 如果老的我的项目在你的手上，你能够尝试的加上这种文档型注解，有助于你前期的重构，或者新性能减少了，对于老接口的了解!

[](# 场景 -1 “ 场景 ”) 场景

咱们来看一个 DTO 转化的场景，对象:

@Data
static class PersonDTO{
  private String dtoName;
  private String dtoAge;
}

@Data
static class Person{
  private String name;
  private String age;
}

需要是将 Person 对象转化成 PersonDTO，而后进行返回。
当然对于实际操作来讲，返回如果 Person 为空，将返回 null, 然而 PersonDTO 是不能返回 null 的（尤其 Rest 接口返回的这种 DTO）。
在这里，咱们只关注转化操作，看如下代码:

@Test
public void shouldConvertDTO(){PersonDTO personDTO = new PersonDTO();

  Person person = new Person();
  if(!Objects.isNull(person)){personDTO.setDtoAge(person.getAge());
    personDTO.setDtoName(person.getName());
  }else{personDTO.setDtoAge("");
    personDTO.setDtoName("");
  }
}

[](# 优化批改 “ 优化批改 ”) 优化批改

这样的数据转化，咱们意识可读性十分差，每个字段的判断，如果是空就设置为空字符串 (“”)

换一种思维形式进行思考，咱们是拿到 Person 这个类的数据，而后进行赋值操作 (setXXX), 其实是不关系 Person 的具体实现是谁的。

那咱们能够创立一个 Person 子类:

static class NullPerson extends Person{
  @Override
  public String getAge() {return "";}

  @Override
  public String getName() {return "";}
}

它作为 Person 的一种特例而存在，如果当 Person 为空的时候，则返回一些 get * 的默认行为.

所以代码能够批改为:

@Test
 public void shouldConvertDTO(){PersonDTO personDTO = new PersonDTO();

   Person person = getPerson();
   personDTO.setDtoAge(person.getAge());
   personDTO.setDtoName(person.getName());
 }

 private Person getPerson(){return new NullPerson();// 如果 Person 是 null , 则返回空对象
 }

其中 getPerson() 办法，能够用来依据业务逻辑获取 Person 有可能的对象（对以后例子来讲，如果 Person 不存在，返回 Person 的的特例 NUllPerson），如果批改成这样，代码的可读性就会变的很强了。

[](# 应用 Optional 能够进行优化 “ 应用 Optional 能够进行优化 ”) 应用 Optional 能够进行优化

空对象模式，它的弊病在于须要创立一个特例对象，然而如果特例的状况比拟多，咱们是不是须要创立多个特例对象呢，尽管咱们也应用了面向对象的多态个性，然而，业务的复杂性如果真的让咱们创立多个特例对象，咱们还是要再三考虑一下这种模式，它可能会带来代码的复杂性。

对于上述代码，还能够应用 Optional 进行优化。

@Test
  public void shouldConvertDTO(){PersonDTO personDTO = new PersonDTO();

    Optional.ofNullable(getPerson()).ifPresent(person -> {personDTO.setDtoAge(person.getAge());
      personDTO.setDtoName(person.getName());
    });
  }

  private Person getPerson(){return null;}

Optional 对空值的应用，我感觉更为贴切，它只实用于”是否存在”的场景。
如果只对管制的存在判断，我倡议应用 Optional.

Optional 如此弱小，它表白了计算机最原始的个性 (0 or 1), 那它如何正确的被应用呢!

[](#Optional 不要作为参数 “Optional 不要作为参数 ”)Optional 不要作为参数

如果你写了一个 public 办法，这个办法规定了一些输出参数，这些参数中有一些是能够传入 null 的，那这时候是否能够应用 Optional 呢？

我给的倡议是: 肯定不要这样应用!

举个例子:

public interface UserService{List<User> listUser(Optional<String> username);
}

这个例子的办法 listUser, 可能在通知咱们须要依据 username 查问所有数据汇合，如果 username 是空，也要返回所有的用户汇合.

当咱们看到这个办法的时候，会感觉有一些歧义:

“如果 username 是 absent, 是返回空集合吗？还是返回全副的用户数据汇合？”

Optioanl 是一种分支的判断，那咱们到底是关注 Optional 还是 Optional.get() 呢？

我给大家的倡议是，如果不想要这样的歧义，就不要应用它！

如果你真的想表白两个含意，就給它拆分出两个接口:

public interface UserService{List<User> listUser(String username);
  List<User> listUser();}

我感觉这样的语义更强，并且更能满足 软件设计准则中的“繁多职责”。

如果你感觉你的入参真的有必要可能传 null, 那请应用 jsr 303 或者 jsr 305 进行阐明和验证!

请记住! Optional 不能作为入参的参数!

[](#Optional 作为返回值 “Optional 作为返回值 ”)Optional 作为返回值

[](# 当个实体的返回 “ 当个实体的返回 ”) 当个实体的返回

那 Optioanl 能够做为返回值吗？
其实它是十分满足是否存在这个语义的。

你如说，你要依据 id 获取用户信息，这个用户有可能存在或者不存在。

你能够这样应用:

public interface UserService{Optional<User> get(Integer id);
}

当调用这个办法的时候，调用者很分明 get 办法返回的数据，有可能不存在，这样能够做一些更正当的判断，更好的避免空指针的谬误！

当然，如果业务方真的须要依据 id 必须查问出 User 的话，就不要这样应用了，请阐明，你要抛出的异样.

只有当思考它返回 null 是正当的状况下，才进行 Optional 的返回

[](# 汇合实体的返回 “ 汇合实体的返回 ”) 汇合实体的返回

不是所有的返回值都能够这样用的！如果你返回的是汇合：

public interface UserService{Optional<List<User>> listUser();
}

这样的返回后果，会让调用者手足无措，是否我判断 Optional 之后，还用进行 isEmpty 的判断呢？

这样带来的返回值歧义！我认为是没有必要的。

咱们要约定，对于 List 这种汇合返回值，如果汇合真的是 null 的，请返回空集合 (Lists.newArrayList);

[](# 应用 Optional 变量 “ 应用 Optional 变量 ”) 应用 Optional 变量 

Optional<User> userOpt = ...

如果有这样的变量 userOpt, 请记住：

  1. 肯定不能间接应用 get，如果这样用，就丢失了 Optional 自身的含意（比方 userOp.get()）
  2. 不要间接应用 getOrThrow , 如果你有这样的需要：获取不到就抛异样。那就要思考，是否是调用的接口设计的是否正当

[](#getter 中的应用 “getter 中的应用 ”)getter 中的应用

对于一个 java bean, 所有的属性都有可能返回 null, 那是否须要改写所有的 getter 成为 Optional 类型呢？

我给大家的倡议是，不要这样滥用 Optional.

即使 我 java bean 中的 getter 是合乎 Optional 的，然而因为 java bean 太多了，这样会导致你的代码有 50% 以上进行 Optinal 的判断，这样便净化了代码。(我想说，其实你的实体中的字段应该都是由业务含意的，会认真的思考过它存在的价值的，不能因为 Optional 的存在而滥用)

咱们应该更关注于业务，而不只是空值的判断。

请不要在 getter 中滥用 Optional.

[](# 小结 -1 “ 小结 ”) 小结

能够这样总结 Optional 的应用：

  1. 当应用值为空的状况，并非源于谬误时，能够应用 Optional!
  2. Optional 不要用于汇合操作!
  3. 不要滥用 Optional, 比方在 java bean 的 getter 中!

举荐浏览

Java 笔记大全.md

太赞了，这个 Java 网站，什么我的项目都有！https://markerhub.com

这个 B 站的 UP 主，讲的 java 真不错！

正文完
java
发表至： java
2021-03-21
 0
关于java:大话云原生煮饺子与dockerkubernetes之间的关系
Java数组排序一云图智联
泛型之泛型方法
深入浅出JVM6栈帧