如何優雅地根治null值引起的Bug?!

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!

常聽到羣裏開發兄弟抱怨,實操時經常看到項目中存在到處空值判斷的情況,這些判斷,會讓人覺得摸不着頭緒,它的出現很有可能和當前的業務邏輯並沒有關係。但着實頭疼。。。

有時候,更可怕的是系統因爲這些空值的情況,會拋出空指針異常,導致業務系統發生問題。本文總結了幾種關於空值的處理手法,分享給大家。

業務中的空值

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

2AD13880_A94D_43a7_A31C_7F28D624B731

問題現場
對於面嚮對象語言來講,抽象層級特別的重要。尤其是對接口的抽象,它在設計和開發中佔很大的比重,我們在開發時希望儘量面向接口編程。

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

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

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

  • listUser() 如果沒有數據,那它是返回空集合還是null呢?
  • get(Integerid) 如果沒有這個對象,是拋異常還是返回null呢?

深入listUser研究

我們先來討論

0E53A408_6127_4ede_BE7B_CEC770DBE184

這段代碼返回是null,從我多年的開發經驗來講,對於集合這樣返回值,最好不要返回null,因爲如果返回了null,會給調用者帶來很多麻煩。你將會把這種調用風險交給調用者來控制。

如果調用者是一個謹慎的人,他會進行是否爲null的條件判斷。如果他並非謹慎,或者他是一個面向接口編程的狂熱分子(當然,面向接口編程是正確的方向),他會按照自己的理解去調用接口,而不進行是否爲null的條件判斷,如果這樣的話,是非常危險的,它很有可能出現空指針異常!

基於此,我們將它進行優化:

4A28EC79_76C4_4465_877C_AA91092A4386

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

深入研究get方法

對於接口

4A3B0E77_3250_4f3b_BBE6_A29369A63276

我們把接口定義加上了說明之後,調用者會看到,如果調用此接口,很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常。
這種方式可以在調用者調用接口的時候看到接口的定義,但是,這種方式是”弱提示”的!關注微信公衆號:互聯網架構師,在後臺回覆:2T,可以獲取我整理的教程,都是乾貨。
如果調用者忽略了註釋,有可能就對業務系統產生了風險,這個風險有可能導致一個億!
除了以上這種”弱提示”的方式,還有一種方式是,返回值是有可能爲空的。那要怎麼辦呢?
我認爲我們需要增加一個接口,用來描述這種場景.
引入jdk8的Optional,或者使用guava的Optional.看如下定義:

8C1267CE_DA9E_4a4c_8C79_E1D4A8E0F8BD

深入入參

通過上述的所有接口的描述,你能確定入參id一定是必傳的嗎?我覺得答案應該是:不能確定。除非接口的文檔註釋上加以說明。
那如何約束入參呢?
推薦兩種方式:

  • 強制約束
  • 文檔性約束(弱提示)

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

BE195633_DA55_4ad1_BA24_894F8F932140

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

2.文檔性約束

在很多時候,我們會遇到遺留代碼,對於遺留代碼,整體性改造的可能性很小。
我們更希望通過閱讀接口的實現,來進行接口的說明。
jsr 305規範,給了我們一個描述接口入參的一個方式(需要引入庫 com.google.code.findbugs:jsr305):
可以使用註解: @Nullable @Nonnull @CheckForNull 進行接口說明。比如:

5A30B831_88D3_4f78_96B8_F692B9EB02E9

小結

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

空對象模式

場景
來看一個DTO轉化的場景,對象:

5F855666_154C_4b89_A0B1_9250574E4C80

優化修改
這樣的數據轉化,可讀性非常差,每個字段的判斷,如果是空就設置爲空字符串(“”)
換一種思維方式進行思考,我們是拿到Person這個類的數據,然後進行賦值操作(setXXX),其實是不關係Person的具體實現是誰的。
那我們可以創建一個Person子類:

8A2D8A3A_A572_49a2_AF3D_30DE71FB4A07

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

使用Optional可以進行優化

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

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

8CDB2268_C5D2_4a93_BAB0_0403073EF20B

Optional對空值的使用,我覺得更爲貼切,它只適用於”是否存在”的場景。
如果只對控制的存在判斷,我建議使用Optional。
Optioanl的正確使用
Optional如此強大,它表達了計算機最原始的特性(0 or 1),那它如何正確的被使用呢!
Optional不要作爲參數
如果你寫了一個public方法,這個方法規定了一些輸入參數,這些參數中有一些是可以傳入null的,那這時候是否可以使用Optional呢?
給的建議是: 一定不要這樣使用!
舉個例子:

194C7604_E045_4ef5_ADBC_9719E88B5554

我覺得這樣的語義更強,並且更能滿足 軟件設計原則中的 “單一職責”。
如果你覺得你的入參真的有必要可能傳null,那請使用jsr 303或者jsr 305進行說明和驗證!
請記住! Optional不能作爲入參的參數!

Optional作爲返回值

當個實體的返回
那Optioanl可以做爲返回值嗎?
其實它是非常滿足是否存在這個語義的。
你如說,你要根據id獲取用戶信息,這個用戶有可能存在或者不存在。
你可以這樣使用:

9FF3070E_D96B_4c30_9120_E041EC21D444

這樣的返回結果,會讓調用者不知所措,是否我判斷Optional之後,還用進行isEmpty的判斷呢?
這樣帶來的返回值歧義!我認爲是沒有必要的。

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

使用Optional變量

B8D4349E_9459_4377_8911_FBCBC3C88BFE

如果有這樣的變量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中!

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/zhibo

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-09
本文作者:互聯網架構師
本文來自:“互聯網架構師”,瞭解相關信息可以關注“互聯網架構師

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章