Java:如何更優雅的處理空值? [復制鏈接]

2019-11-12 10:14
SoftwareGames 閱讀:377 評論:0 贊:0
Tag:  Java 空值

導語

在筆者幾年的開發經驗中,經常看到項目中存在到處空值判斷的情況,這些判斷,會讓人覺得摸不著頭緒,它的出現很有可能和當前的業務邏輯并沒有關系。但它會讓你很頭疼。

有時候,更可怕的是系統因為這些空值的情況,會拋出空指針異常,導致業務系統發生問題。

此篇文章,我總結了幾種關于空值的處理手法,希望對讀者有幫助。

業務中的空值

場景

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

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

問題現場

對于面向對象語言來講,抽象層級特別的重要。尤其是對接口的抽象,它在設計和開發中占很大的比重,我們在開發時希望盡量面向接口編程。

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

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

在所有的開發中,XP推崇的TDD模式可以很好的引導我們對接口的定義,所以我們將TDD作為開發代碼的”推動者”。

對于以上的接口,當我們使用TDD進行測試用例先行時,發現了潛在的問題:

  • listUser() 如果沒有數據,那它是返回空集合還是null呢?
  • get(Integer id) 如果沒有這個對象,是拋異常還是返回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;
}

對于接口(List listUser()),它一定會返回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中!

我來說兩句
您需要登錄后才可以評論 登錄 | 立即注冊
facelist
所有評論(0)
領先的中文移動開發者社區
18620764416
7*24全天服務
意見反饋:[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 粵ICP備15117877號 )

龙江福彩p62开奖 用手机如何兼职赚钱吗 教你网络捕鱼怎样打 顺风车跑长途还是短途赚钱 好彩网首页 为什么做亮碧思的朋友都觉得很赚钱 不要命了什么职业赚钱 双路2680做什么赚钱 新闻赚钱下载 金祥彩票游戏 万马赚钱 旅游婚礼赚钱吗 聚亨捕鱼来了官网 换日元怎么赚钱 集体融资买股票能赚钱么 网络捕鱼游戏92平台 大学赚钱创意点子