點擊上方?SpringForAll社區?輕松關注！及時獲取有趣有料的技術文章

來源：

http://lrwinx.github.io/2018/08/30/java匠人手法-優雅的處理空值/

導語

在筆者幾年的開發經驗中，經常看到項目中存在到處空值判斷的情況，這些判斷，會讓人覺得摸不這頭緒，它的出現很有可能和當前的業務邏輯并沒有關系。但它會讓你很頭疼。
有時候，更可怕的是系統因為這些空值的情況，會拋出空指針異常，導致業務系統發生問題。
此篇文章，我總結了幾種關于空值的處理手法，希望對讀者有幫助。

場景

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

1public?interface?UserSearchService{
2??List?listUser();
3
4??User?get(Integer?id);
5}

問題現場

對于面向對象語言來講，抽象層級特別的重要。尤其是對接口的抽象，它在設計和開發中占很大的比重，我們在開發時希望盡量面向接口編程。
對于以上描述的接口方法來看，大概可以推斷出可能它包含了以下兩個含義:

listUser(): 查詢用戶列表

get(Integer id): 查詢單個用戶

在所有的開發中，XP推崇的TDD模式可以很好的引導我們對接口的定義，所以我們將TDD作為開發代碼的”推動者”。
對于以上的接口，當我們使用TDD進行測試用例先行時，發現了潛在的問題：

listUser() 如果沒有數據，那它是返回空集合還是null呢？

get(Integer id) 如果沒有這個對象，是拋異常還是返回null呢？

深入listUser研究

我們先來討論

1listUser()

這個接口，我經常看到如下實現:

1public?List?listUser(){2????List?userList?=?userListRepostity.selectByExample(new?UserExample());3????if(CollectionUtils.isEmpty(userList)){//spring?util工具類4??????return?null;5????}6????return?userList;7}

這段代碼返回是null,從我多年的開發經驗來講，對于集合這樣返回值，最好不要返回null，因為如果返回了null，會給調用者帶來很多麻煩。你將會把這種調用風險交給調用者來控制。
如果調用者是一個謹慎的人，他會進行是否為null的條件判斷。如果他并非謹慎，或者他是一個面向接口編程的狂熱分子(當然，面向接口編程是正確的方向)，他會按照自己的理解去調用接口，而不進行是否為null的條件判斷，如果這樣的話，是非常危險的，它很有可能出現空指針異常！
根據墨菲定律來判斷: “很有可能出現的問題，在將來一定會出現!”

基于此，我們將它進行優化:

1public?List?listUser(){2????List?userList?=?userListRepostity.selectByExample(new?UserExample());3????if(CollectionUtils.isEmpty(userList)){4??????return?Lists.newArrayList();//guava類庫提供的方式5????}6????return?userList;7}

對于接口(List listUser())，它一定會返回List，即使沒有數據，它仍然會返回List(集合中沒有任何元素);
通過以上的修改，我們成功的避免了有可能發生的空指針異常，這樣的寫法更安全！

深入研究get方法

對于接口

1User?get(Integer?id)

你能看到的現象是，我給出id，它一定會給我返回User.但事實真的很有可能不是這樣的。

我看到過的實現:

1public?User?get(Integer?id){
2??return?userRepository.selectByPrimaryKey(id);//從數據庫中通過id直接獲取實體對象
3}

相信很多人也都會這樣寫。
通過代碼的時候得知它的返回值很有可能是null! 但我們通過的接口是分辨不出來的!
這個是個非常危險的事情。尤其對于調用者來說！

我給出的建議是，需要在接口明明時補充文檔,比如對于異常的說明,使用注解@exception:

1public?interface?UserSearchService{
2
3??/** 4???*?根據用戶id獲取用戶信息 5???*?@param?id?用戶id 6???*?@return?用戶實體 7???*?@exception?UserNotFoundException 8???*/
9??User?get(Integer?id);
10
11}

我們把接口定義加上了說明之后，調用者會看到，如果調用此接口，很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常。

這種方式可以在調用者調用接口的時候看到接口的定義，但是，這種方式是”弱提示”的！
如果調用者忽略了注釋，有可能就對業務系統產生了風險，這個風險有可能導致一個億！

除了以上這種”弱提示”的方式，還有一種方式是，返回值是有可能為空的。那要怎么辦呢？
我認為我們需要增加一個接口，用來描述這種場景.
引入jdk8的Optional,或者使用guava的Optional.看如下定義:

1public?interface?UserSearchService{
2
3??/**4???*?根據用戶id獲取用戶信息5???*?@param?id?用戶id6???*?@return?用戶實體,此實體有可能是缺省值7???*/
8??Optional?getOptional(Integer?id);
9}

Optional有兩個含義: 存在 or 缺省。

那么通過閱讀接口getOptional()，我們可以很快的了解返回值的意圖，這個其實是我們想看到的，它去除了二義性。

它的實現可以寫成:

1public?Optional?getOptional(Integer?id){
2??return?Optional.ofNullable(userRepository.selectByPrimaryKey(id));
3}

深入入參

通過上述的所有接口的描述，你能確定入參id一定是必傳的嗎？我覺得答案應該是：不能確定。除非接口的文檔注釋上加以說明。

那如何約束入參呢?

我給大家推薦兩種方式：

強制約束

文檔性約束(弱提示)

1.強制約束，我們可以通過jsr 303進行嚴格的約束聲明:

1public?interface?UserSearchService{
2??/** 3???*?根據用戶id獲取用戶信息 4???*?@param?id?用戶id 5???*?@return?用戶實體 6???*?@exception?UserNotFoundException 7???*/
8??User?get(@NotNull?Integer?id);
9
10??/**11???*?根據用戶id獲取用戶信息12???*?@param?id?用戶id13???*?@return?用戶實體,此實體有可能是缺省值14???*/
15??Optional?getOptional(@NotNull?Integer?id);16}

當然，這樣寫，要配合AOP的操作進行驗證，但讓spring已經提供了很好的集成方案，在此我就不在贅述了。

2.文檔性約束

在很多時候，我們會遇到遺留代碼，對于遺留代碼，整體性改造的可能性很小。
我們更希望通過閱讀接口的實現，來進行接口的說明。
jsr 305規范，給了我們一個描述接口入參的一個方式(需要引入庫 com.google.code.findbugs:jsr305):

可以使用注解: @Nullable @Nonnull @CheckForNull 進行接口說明。
比如:

1public?interface?UserSearchService{
2??/** 3???*?根據用戶id獲取用戶信息 4???*?@param?id?用戶id 5???*?@return?用戶實體 6???*?@exception?UserNotFoundException 7???*/
8??@CheckForNull
9??User?get(@NonNull?Integer?id);
10
11??/**12???*?根據用戶id獲取用戶信息13???*?@param?id?用戶id14???*?@return?用戶實體,此實體有可能是缺省值15???*/
16??Optional?getOptional(@NonNull?Integer?id);17}

小結

通過 空集合返回值,Optional,jsr 303，jsr 305這幾種方式，可以讓我們的代碼可讀性更強，出錯率更低！

空集合返回值 ：如果有集合這樣返回值時，除非真的有說服自己的理由，否則，一定要返回空集合，而不是null

Optional: 如果你的代碼是jdk8，就引入它！如果不是，則使用Guava的Optional,或者升級jdk版本！它很大程度的能增加了接口的可讀性！

jsr 303: 如果新的項目正在開發，不防加上這個試試！一定有一種特別爽的感覺!

jsr 305: 如果老的項目在你的手上，你可以嘗試的加上這種文檔型注解，有助于你后期的重構，或者新功能增加了，對于老接口的理解!

空對象模式

場景

我們來看一個DTO轉化的場景，對象:

1@Data
2static?class?PersonDTO{
3??private?String?dtoName;
4??private?String?dtoAge;
5}
6
7@Data
8static?class?Person{
9??private?String?name;
10??private?String?age;
11}

需求是將Person對象轉化成PersonDTO，然后進行返回。
當然對于實際操作來講，返回如果Person為空，將返回null,但是PersonDTO是不能返回null的(尤其Rest接口返回的這種DTO)。
在這里，我們只關注轉化操作，看如下代碼:

1@Test
2public?void?shouldConvertDTO(){
3
4??PersonDTO?personDTO?=?new?PersonDTO();
5
6??Person?person?=?new?Person();
7??if(!Objects.isNull(person)){
8????personDTO.setDtoAge(person.getAge());
9????personDTO.setDtoName(person.getName());
10??}else{
11????personDTO.setDtoAge("");
12????personDTO.setDtoName("");
13??}
14}

優化修改

這樣的數據轉化，我們認識可讀性非常差，每個字段的判斷，如果是空就設置為空字符串(“”)

換一種思維方式進行思考，我們是拿到Person這個類的數據，然后進行賦值操作(setXXX),其實是不關系Person的具體實現是誰的。

那我們可以創建一個Person子類:

1static?class?NullPerson?extends?Person{
2??@Override
3??public?String?getAge()?{
4????return?"";
5??}
6
7??@Override
8??public?String?getName()?{
9????return?"";
10??}
11}

它作為Person的一種特例而存在，如果當Person為空的時候，則返回一些get*的默認行為.

所以代碼可以修改為:

1@Test
2?public?void?shouldConvertDTO(){
3
4???PersonDTO?personDTO?=?new?PersonDTO();
5
6???Person?person?=?getPerson();
7???personDTO.setDtoAge(person.getAge());
8???personDTO.setDtoName(person.getName());
9?}
10
11?private?Person?getPerson(){
12???return?new?NullPerson();//如果Person是null?,則返回空對象
13?}

其中getPerson()方法，可以用來根據業務邏輯獲取Person有可能的對象(對當前例子來講，如果Person不存在，返回Person的的特例NUllPerson)，如果修改成這樣，代碼的可讀性就會變的很強了。

使用Optional可以進行優化

空對象模式，它的弊端在于需要創建一個特例對象，但是如果特例的情況比較多，我們是不是需要創建多個特例對象呢，雖然我們也使用了面向對象的多態特性，但是，業務的復雜性如果真的讓我們創建多個特例對象，我們還是要再三考慮一下這種模式，它可能會帶來代碼的復雜性。

對于上述代碼，還可以使用Optional進行優化。

1@Test
2??public?void?shouldConvertDTO(){
3
4????PersonDTO?personDTO?=?new?PersonDTO();
5
6????Optional.ofNullable(getPerson()).ifPresent(person?->?{
7??????personDTO.setDtoAge(person.getAge());
8??????personDTO.setDtoName(person.getName());
9????});
10??}
11
12??private?Person?getPerson(){
13????return?null;
14??}

Optional對空值的使用，我覺得更為貼切，它只適用于”是否存在”的場景。
如果只對控制的存在判斷，我建議使用Optional.

Optioanl的正確使用

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

Optional不要作為參數

如果你寫了一個public方法，這個方法規定了一些輸入參數，這些參數中有一些是可以傳入null的，那這時候是否可以使用Optional呢？

我給的建議是: 一定不要這樣使用!

舉個例子:

1public?interface?UserService{
2??List?listUser(Optional?username);
3}

這個例子的方法 listUser,可能在告訴我們需要根據username查詢所有數據集合，如果username是空，也要返回所有的用戶集合.

當我們看到這個方法的時候，會覺得有一些歧義:

“如果username是absent,是返回空集合嗎？還是返回全部的用戶數據集合？”

Optioanl是一種分支的判斷，那我們究竟是關注 Optional還是Optional.get()呢？

我給大家的建議是，如果不想要這樣的歧義，就不要使用它！

如果你真的想表達兩個含義，就給它拆分出兩個接口:

1public?interface?UserService{
2??List?listUser(String?username);
3??List?listUser();
4}

我覺得這樣的語義更強，并且更能滿足 軟件設計原則中的 “單一職責”。

如果你覺得你的入參真的有必要可能傳null,那請使用jsr 303或者jsr 305進行說明和驗證!

請記住! Optional不能作為入參的參數!

Optional作為返回值

當個實體的返回

那Optioanl可以做為返回值嗎？
其實它是非常滿足是否存在這個語義的。

你如說，你要根據id獲取用戶信息，這個用戶有可能存在或者不存在。

你可以這樣使用:

1public?interface?UserService{
2??Optional?get(Integer?id);
3}

當調用這個方法的時候，調用者很清楚get方法返回的數據，有可能不存在，這樣可以做一些更合理的判斷，更好的防止空指針的錯誤！

當然，如果業務方真的需要根據id必須查詢出User的話，就不要這樣使用了，請說明，你要拋出的異常.

只有當考慮它返回null是合理的情況下，才進行Optional的返回

集合實體的返回

不是所有的返回值都可以這樣用的！如果你返回的是集合：

1public?interface?UserService{
2??Optional<List>?listUser();3}

這樣的返回結果，會讓調用者不知所措，是否我判斷Optional之后，還用進行isEmpty的判斷呢？

這樣帶來的返回值歧義！我認為是沒有必要的。

我們要約定，對于List這種集合返回值，如果集合真的是null的，請返回空集合(Lists.newArrayList);

使用Optional變量

1Optional<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中!

●?深入淺出 CAS

●?Spring Boot Devtools熱部署

●?Spring Boot AOP記錄用戶操作日志

●?Spring Boot整合Mongo DB

●?【圖文講解】你一定能看懂的HTTPS原理剖析！

●??基礎面試，為什么面試官總喜歡問String？

●??Spring Boot Admin 2.2.0發布，支持最新Spring Boot/Cloud之外，新增中文展示！

●??你應該知道的 @ConfigurationProperties 注解的使用姿勢，這一篇就夠了

如有收獲，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！

總結

以上是生活随笔為你收集整理的一个空值_java匠人手法优雅的处理空值的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。