国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

打開APP
userphoto
未登錄

開通VIP,暢享免費(fèi)電子書等14項(xiàng)超值服

開通VIP
Java到底如何更優(yōu)雅的處理空值?

來源:https://lrwinx.github.io

在筆者幾年的開發(fā)經(jīng)驗(yàn)中,經(jīng)??吹巾?xiàng)目中存在到處空值判斷的情況,這些判斷,會(huì)讓人覺得摸不著頭緒,它的出現(xiàn)很有可能和當(dāng)前的業(yè)務(wù)邏輯并沒有關(guān)系。但它會(huì)讓你很頭疼。
有時(shí)候,更可怕的是系統(tǒng)因?yàn)檫@些空值的情況,會(huì)拋出空指針異常,導(dǎo)致業(yè)務(wù)系統(tǒng)發(fā)生問題。
此篇文章,我總結(jié)了幾種關(guān)于空值的處理手法,希望對(duì)讀者有幫助。


業(yè)務(wù)中的空值

場(chǎng)景

存在一個(gè)UserSearchService用來提供用戶查詢的功能:
public interface UserSearchService{
  List<User> listUser();

  User get(Integer id);
}

問題現(xiàn)場(chǎng)

對(duì)于面向?qū)ο笳Z言來講,抽象層級(jí)特別的重要。尤其是對(duì)接口的抽象,它在設(shè)計(jì)和開發(fā)中占很大的比重,我們?cè)陂_發(fā)時(shí)希望盡量面向接口編程。
對(duì)于以上描述的接口方法來看,大概可以推斷出可能它包含了以下兩個(gè)含義:
  • listUser(): 查詢用戶列表
  • get(Integer id): 查詢單個(gè)用戶
在所有的開發(fā)中,XP推崇的TDD模式可以很好的引導(dǎo)我們對(duì)接口的定義,所以我們將TDD作為開發(fā)代碼的”推動(dòng)者”。
對(duì)于以上的接口,當(dāng)我們使用TDD進(jìn)行測(cè)試用例先行時(shí),發(fā)現(xiàn)了潛在的問題:
  • listUser() 如果沒有數(shù)據(jù),那它是返回空集合還是null呢?
  • get(Integer id) 如果沒有這個(gè)對(duì)象,是拋異常還是返回null呢?

深入listUser研究

我們先來討論
listUser()

這個(gè)接口,我經(jīng)??吹饺缦聦?shí)現(xiàn):

public List<User> listUser(){
    List<User> userList = userListRepostity.selectByExample(new UserExample());
    if(CollectionUtils.isEmpty(userList)){//spring util工具類
      return null;
    }
    return userList;
}
這段代碼返回是null,從我多年的開發(fā)經(jīng)驗(yàn)來講,對(duì)于集合這樣返回值,最好不要返回null,因?yàn)槿绻祷亓薾ull,會(huì)給調(diào)用者帶來很多麻煩。你將會(huì)把這種調(diào)用風(fēng)險(xiǎn)交給調(diào)用者來控制。
如果調(diào)用者是一個(gè)謹(jǐn)慎的人,他會(huì)進(jìn)行是否為null的條件判斷。如果他并非謹(jǐn)慎,或者他是一個(gè)面向接口編程的狂熱分子(當(dāng)然,面向接口編程是正確的方向),他會(huì)按照自己的理解去調(diào)用接口,而不進(jìn)行是否為null的條件判斷,如果這樣的話,是非常危險(xiǎn)的,它很有可能出現(xiàn)空指針異常!
根據(jù)墨菲定律來判斷: “很有可能出現(xiàn)的問題,在將來一定會(huì)出現(xiàn)!”
基于此,我們將它進(jìn)行優(yōu)化:
public List<User> listUser(){
    List<User> userList = userListRepostity.selectByExample(new UserExample());
    if(CollectionUtils.isEmpty(userList)){
      return Lists.newArrayList();//guava類庫提供的方式
    }
    return userList;
}
對(duì)于接口(List listUser()),它一定會(huì)返回List,即使沒有數(shù)據(jù),它仍然會(huì)返回List(集合中沒有任何元素);
通過以上的修改,我們成功的避免了有可能發(fā)生的空指針異常,這樣的寫法更安全!

深入研究get方法

對(duì)于接口
User get(Integer id)
你能看到的現(xiàn)象是,我給出id,它一定會(huì)給我返回User.但事實(shí)真的很有可能不是這樣的。
我看到過的實(shí)現(xiàn):
public User get(Integer id){
  return userRepository.selectByPrimaryKey(id);//從數(shù)據(jù)庫中通過id直接獲取實(shí)體對(duì)象
}
相信很多人也都會(huì)這樣寫。
通過代碼的時(shí)候得知它的返回值很有可能是null! 但我們通過的接口是分辨不出來的!
這個(gè)是個(gè)非常危險(xiǎn)的事情。尤其對(duì)于調(diào)用者來說!
我給出的建議是,需要在接口明明時(shí)補(bǔ)充文檔,比如對(duì)于異常的說明,使用注解@exception:
public interface UserSearchService{

  /**
   * 根據(jù)用戶id獲取用戶信息
   * @param id 用戶id
   * @return 用戶實(shí)體
   * @exception UserNotFoundException
   */
  User get(Integer id);

}
我們把接口定義加上了說明之后,調(diào)用者會(huì)看到,如果調(diào)用此接口,很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常。
這種方式可以在調(diào)用者調(diào)用接口的時(shí)候看到接口的定義,但是,這種方式是”弱提示”的!
如果調(diào)用者忽略了注釋,有可能就對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生了風(fēng)險(xiǎn),這個(gè)風(fēng)險(xiǎn)有可能導(dǎo)致一個(gè)億!
除了以上這種”弱提示”的方式,還有一種方式是,返回值是有可能為空的。那要怎么辦呢?
我認(rèn)為我們需要增加一個(gè)接口,用來描述這種場(chǎng)景.
引入jdk8的Optional,或者使用guava的Optional.看如下定義:
public interface UserSearchService{

  /**
   * 根據(jù)用戶id獲取用戶信息
   * @param id 用戶id
   * @return 用戶實(shí)體,此實(shí)體有可能是缺省值
   */
  Optional<User> getOptional(Integer id);
}
Optional有兩個(gè)含義: 存在 or 缺省。
那么通過閱讀接口getOptional(),我們可以很快的了解返回值的意圖,這個(gè)其實(shí)是我們想看到的,它去除了二義性。
它的實(shí)現(xiàn)可以寫成:
public Optional<User> getOptional(Integer id){
  return Optional.ofNullable(userRepository.selectByPrimaryKey(id));
}

深入入?yún)?/strong>

通過上述的所有接口的描述,你能確定入?yún)d一定是必傳的嗎?我覺得答案應(yīng)該是:不能確定。除非接口的文檔注釋上加以說明。
那如何約束入?yún)⒛?
我給大家推薦兩種方式:
  • 強(qiáng)制約束
  • 文檔性約束(弱提示)
1.強(qiáng)制約束,我們可以通過jsr 303進(jìn)行嚴(yán)格的約束聲明:
public interface UserSearchService{
  /**
   * 根據(jù)用戶id獲取用戶信息
   * @param id 用戶id
   * @return 用戶實(shí)體
   * @exception UserNotFoundException
   */
  User get(@NotNull Integer id);

  /**
   * 根據(jù)用戶id獲取用戶信息
   * @param id 用戶id
   * @return 用戶實(shí)體,此實(shí)體有可能是缺省值
   */
  Optional<User> getOptional(@NotNull Integer id);
}
當(dāng)然,這樣寫,要配合AOP的操作進(jìn)行驗(yàn)證,但讓spring已經(jīng)提供了很好的集成方案,在此我就不在贅述了。關(guān)注微信公眾號(hào):Java技術(shù)棧,在后臺(tái)回復(fù):spring,可以獲取我整理的 N 篇最新 Spring 系列教程,都是干貨。
2.文檔性約束
在很多時(shí)候,我們會(huì)遇到遺留代碼,對(duì)于遺留代碼,整體性改造的可能性很小。
我們更希望通過閱讀接口的實(shí)現(xiàn),來進(jìn)行接口的說明。
jsr 305規(guī)范,給了我們一個(gè)描述接口入?yún)⒌囊粋€(gè)方式(需要引入庫 com.google.code.findbugs:jsr305):
可以使用注解: @Nullable @Nonnull @CheckForNull 進(jìn)行接口說明。
比如:
public interface UserSearchService{
  /**
   * 根據(jù)用戶id獲取用戶信息
   * @param id 用戶id
   * @return 用戶實(shí)體
   * @exception UserNotFoundException
   */
  @CheckForNull
  User get(@NonNull Integer id);

  /**
   * 根據(jù)用戶id獲取用戶信息
   * @param id 用戶id
   * @return 用戶實(shí)體,此實(shí)體有可能是缺省值
   */
  Optional<User> getOptional(@NonNull Integer id);
}

小結(jié)

通過 空集合返回值,Optional,jsr 303,jsr 305這幾種方式,可以讓我們的代碼可讀性更強(qiáng),出錯(cuò)率更低!
  • 空集合返回值 :如果有集合這樣返回值時(shí),除非真的有說服自己的理由,否則,一定要返回空集合,而不是null
  • Optional: 如果你的代碼是jdk8,就引入它!如果不是,則使用Guava的Optional,或者升級(jí)jdk版本!它很大程度的能增加了接口的可讀性!
  • jsr 303: 如果新的項(xiàng)目正在開發(fā),不防加上這個(gè)試試!一定有一種特別爽的感覺!
  • jsr 305: 如果老的項(xiàng)目在你的手上,你可以嘗試的加上這種文檔型注解,有助于你后期的重構(gòu),或者新功能增加了,對(duì)于老接口的理解!


空對(duì)象模式

場(chǎng)景

我們來看一個(gè)DTO轉(zhuǎn)化的場(chǎng)景,對(duì)象:
@Data
static class PersonDTO{
  private String dtoName;
  private String dtoAge;
}

@Data
static class Person{
  private String name;
  private String age;
}
需求是將Person對(duì)象轉(zhuǎn)化成PersonDTO,然后進(jìn)行返回。
當(dāng)然對(duì)于實(shí)際操作來講,返回如果Person為空,將返回null,但是PersonDTO是不能返回null的(尤其Rest接口返回的這種DTO)。
在這里,我們只關(guān)注轉(zhuǎn)化操作,看如下代碼:
@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('');
  }
}

優(yōu)化修改

這樣的數(shù)據(jù)轉(zhuǎn)化,我們認(rèn)識(shí)可讀性非常差,每個(gè)字段的判斷,如果是空就設(shè)置為空字符串(“”)
換一種思維方式進(jìn)行思考,我們是拿到Person這個(gè)類的數(shù)據(jù),然后進(jìn)行賦值操作(setXXX),其實(shí)是不關(guān)系Person的具體實(shí)現(xiàn)是誰的。
那我們可以創(chuàng)建一個(gè)Person子類:
static class NullPerson extends Person{
  @Override
  public String getAge() {
    return '';
  }

  @Override
  public String getName() {
    return '';
  }
}
它作為Person的一種特例而存在,如果當(dāng)Person為空的時(shí)候,則返回一些get*的默認(rèn)行為.
所以代碼可以修改為:
@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 ,則返回空對(duì)象
 }
其中g(shù)etPerson()方法,可以用來根據(jù)業(yè)務(wù)邏輯獲取Person有可能的對(duì)象(對(duì)當(dāng)前例子來講,如果Person不存在,返回Person的的特例NUllPerson),如果修改成這樣,代碼的可讀性就會(huì)變的很強(qiáng)了。

使用Optional可以進(jìn)行優(yōu)化

空對(duì)象模式,它的弊端在于需要?jiǎng)?chuàng)建一個(gè)特例對(duì)象,但是如果特例的情況比較多,我們是不是需要?jiǎng)?chuàng)建多個(gè)特例對(duì)象呢,雖然我們也使用了面向?qū)ο蟮亩鄳B(tài)特性,但是,業(yè)務(wù)的復(fù)雜性如果真的讓我們創(chuàng)建多個(gè)特例對(duì)象,我們還是要再三考慮一下這種模式,它可能會(huì)帶來代碼的復(fù)雜性。
對(duì)于上述代碼,還可以使用Optional進(jìn)行優(yōu)化。
@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對(duì)空值的使用,我覺得更為貼切,它只適用于”是否存在”的場(chǎng)景。
如果只對(duì)控制的存在判斷,我建議使用Optional。

Optioanl的正確使用

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

Optional不要作為參數(shù)

如果你寫了一個(gè)public方法,這個(gè)方法規(guī)定了一些輸入?yún)?shù),這些參數(shù)中有一些是可以傳入null的,那這時(shí)候是否可以使用Optional呢?
我給的建議是: 一定不要這樣使用!
舉個(gè)例子:
public interface UserService{
  List<User> listUser(Optional<String> username);
}
這個(gè)例子的方法 listUser,可能在告訴我們需要根據(jù)username查詢所有數(shù)據(jù)集合,如果username是空,也要返回所有的用戶集合.
當(dāng)我們看到這個(gè)方法的時(shí)候,會(huì)覺得有一些歧義:
“如果username是absent,是返回空集合嗎?還是返回全部的用戶數(shù)據(jù)集合?”
Optional是一種分支的判斷,那我們究竟是關(guān)注 Optional還是Optional.get()呢?
我給大家的建議是,如果不想要這樣的歧義,就不要使用它!
如果你真的想表達(dá)兩個(gè)含義,就給它拆分出兩個(gè)接口:
public interface UserService{
  List<User> listUser(String username);
  List<User> listUser();
}
我覺得這樣的語義更強(qiáng),并且更能滿足 軟件設(shè)計(jì)原則中的 “單一職責(zé)”。
如果你覺得你的入?yún)⒄娴挠斜匾赡軅鱪ull,那請(qǐng)使用jsr 303或者jsr 305進(jìn)行說明和驗(yàn)證!
請(qǐng)記住! Optional不能作為入?yún)⒌膮?shù)!


Optional作為返回值

當(dāng)個(gè)實(shí)體的返回

Optional可以做為返回值嗎?
其實(shí)它是非常滿足是否存在這個(gè)語義的。
你如說,你要根據(jù)id獲取用戶信息,這個(gè)用戶有可能存在或者不存在。
你可以這樣使用:
public interface UserService{
  Optional<User> get(Integer id);
}
當(dāng)調(diào)用這個(gè)方法的時(shí)候,調(diào)用者很清楚get方法返回的數(shù)據(jù),有可能不存在,這樣可以做一些更合理的判斷,更好的防止空指針的錯(cuò)誤!
當(dāng)然,如果業(yè)務(wù)方真的需要根據(jù)id必須查詢出User的話,就不要這樣使用了,請(qǐng)說明,你要拋出的異常.
只有當(dāng)考慮它返回null是合理的情況下,才進(jìn)行Optional的返回

集合實(shí)體的返回

不是所有的返回值都可以這樣用的!如果你返回的是集合:
public interface UserService{
  Optional<List<User>> listUser();
}
這樣的返回結(jié)果,會(huì)讓調(diào)用者不知所措,是否我判斷Optional之后,還用進(jìn)行isEmpty的判斷呢?
這樣帶來的返回值歧義!我認(rèn)為是沒有必要的。
我們要約定,對(duì)于List這種集合返回值,如果集合真的是null的,請(qǐng)返回空集合(Lists.newArrayList);


使用Optional變量



Optional<User> userOpt = ...
如果有這樣的變量userOpt,請(qǐng)記住 :
  • 一定不能直接使用get ,如果這樣用,就喪失了Optional本身的含義 ( 比如userOp.get() )
  • 不要直接使用getOrThrow ,如果你有這樣的需求:獲取不到就拋異常。那就要考慮,是否是調(diào)用的接口設(shè)計(jì)的是否合理

getter中的使用

對(duì)于一個(gè)java bean,所有的屬性都有可能返回null,那是否需要改寫所有的getter成為Optional類型呢?
我給大家的建議是,不要這樣濫用Optional.
即便 我java bean中的getter是符合Optional的,但是因?yàn)閖ava bean 太多了,這樣會(huì)導(dǎo)致你的代碼有50%以上進(jìn)行Optional的判斷,這樣便污染了代碼。(我想說,其實(shí)你的實(shí)體中的字段應(yīng)該都是由業(yè)務(wù)含義的,會(huì)認(rèn)真的思考過它存在的價(jià)值的,不能因?yàn)镺ptional的存在而濫用)
我們應(yīng)該更關(guān)注于業(yè)務(wù),而不只是空值的判斷。
請(qǐng)不要在getter中濫用Optional.

小結(jié)

可以這樣總結(jié)Optional的使用:
  • 當(dāng)使用值為空的情況,并非源于錯(cuò)誤時(shí),可以使用Optional
  • Optional不要用于集合操作!
  • 不要濫用Optional,比如在java bean的getter中!
本站僅提供存儲(chǔ)服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊舉報(bào)。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
生活服務(wù)
分享 收藏 導(dǎo)長圖 關(guān)注 下載文章
綁定賬號(hào)成功
后續(xù)可登錄賬號(hào)暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點(diǎn)擊這里聯(lián)系客服!

聯(lián)系客服