如何優雅地根治null值引發的Bug！

本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分佈式等教程，一共30G，須要本身領取。
傳送門：https://mp.weixin.qq.com/s/igMojff-bbmQ6irCGO3mqA

在筆者幾年的開發經驗中，常常看到項目中存在處處空值判斷的狀況，這些判斷，會讓人以爲摸不着頭緒，它的出現頗有可能和當前的業務邏輯並無關係。但它會讓你很頭疼。

有時候，更可怕的是系統由於這些空值的狀況，會拋出空指針異常，致使業務系統發生問題。

此篇文章，總結了幾種關於空值的處理手法，但願對讀者有幫助。

業務中的空值

場景

存在一個 UserSearchService用來提供用戶查詢的功能：

public interface UserSearchService{
 List<User> listUser();
 User get(Integer id);
}

 

問題現場

對於面嚮對象語言來說，抽象層級特別的重要。尤爲是對接口的抽象，它在設計和開發中佔很大的比重，咱們在開發時但願儘可能面向接口編程。

對於以上描述的接口方法來看，大概能夠推斷出可能它包含了如下兩個含義:

• listUser(): 查詢用戶列表
• get(Integerid): 查詢單個用戶

在全部的開發中，XP推崇的TDD模式能夠很好的引導咱們對接口的定義，因此咱們將TDD做爲開發代碼的」推進者」。

對於以上的接口，當咱們使用TDD進行測試用例先行時，發現了潛在的問題：

• listUser() 若是沒有數據，那它是返回空集合仍是null呢？
• get(Integerid) 若是沒有這個對象，是拋異常仍是返回null呢？

深刻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;
}

 

 

對於接口( ListlistUser())，它必定會返回List，即便沒有數據，它仍然會返回List（集合中沒有任何元素）;

經過以上的修改，咱們成功的避免了有可能發生的空指針異常，這樣的寫法更安全！

深刻研究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.強制約束，咱們能夠經過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已經提供了很好的集成方案，在此就不在贅述了。

2.文檔性約束

在不少時候，咱們會遇到遺留代碼，對於遺留代碼，總體性改造的可能性很小。

咱們更但願經過閱讀接口的實現，來進行接口的說明。

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這幾種方式，可讓咱們的代碼可讀性更強，出錯率更低！

• 空集合返回值 ：若是有集合這樣返回值時，除非真的有說服本身的理由，不然，必定要返回空集合，而不是null
• Optional: 若是你的代碼是jdk8，就引入它！若是不是，則使用Guava的Optional,或者升級jdk版本！它很大程度的能增長了接口的可讀性！
• jsr 303: 若是新的項目正在開發，不防加上這個試試！必定有一種特別爽的感受!
• jsr 305: 若是老的項目在你的手上，你能夠嘗試的加上這種文檔型註解，有助於你後期的重構，或者新功能增長了，對於老接口的理解!

空對象模式

場景

來看一個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進行優化。

@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。

Optioanl的正確使用

Optional如此強大，它表達了計算機最原始的特性(0 or 1),那它如何正確的被使用呢!

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做爲返回值

當個實體的返回

那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<User> userOpt = ...

 

 

若是有這樣的變量userOpt,請記住 ：

• 必定不能直接使用get ，若是這樣用，就喪失了Optional自己的含義 （ 好比userOp.get() ）
• 不要直接使用getOrThrow ,若是你有這樣的需求：獲取不到就拋異常。那就要考慮，是不是調用的接口設計的是否合理

getter中的使用

對於一個java bean,全部的屬性都有可能返回null,那是否須要改寫全部的getter成爲Optional類型呢？

給你們的建議是，不要這樣濫用Optional.

即使 我java bean中的getter是符合Optional的，可是由於java bean 太多了，這樣會致使你的代碼有50%以上進行Optinal的判斷，這樣便污染了代碼。(我想說，其實你的實體中的字段應該都是由業務含義的，會認真的思考過它存在的價值的，不能由於Optional的存在而濫用)

咱們應該更關注於業務，而不僅是空值的判斷。

不要在getter中濫用Optional.

小結

能夠這樣總結Optional的使用：

• 當使用值爲空的狀況，並不是源於錯誤時，可使用Optional!
• Optional不要用於集合操做!
• 不要濫用Optional,好比在java bean的getter中!