常聽(tīng)到群里開(kāi)發(fā)兄弟抱怨，實(shí)操時(shí)經(jīng)?？吹巾?xiàng)目中存在到處空值判斷的情況，這些判斷，會(huì)讓人覺(jué)得摸不著頭緒，它的出現(xiàn)很有可能和當(dāng)前的業(yè)務(wù)邏輯并沒(méi)有關(guān)系。但著實(shí)頭疼。。。 有時(shí)候，更可怕的是系統(tǒng)因?yàn)檫@些空值的情況，會(huì)拋出空指針異常，導(dǎo)致業(yè)務(wù)系統(tǒng)發(fā)生問(wèn)題。本文總結(jié)了幾種關(guān)于空值的處理手法，分享給大家。 **業(yè)務(wù)中的空值** 場(chǎng)景 存在一個(gè) UserSearchService用來(lái)提供用戶查詢的功能： **問(wèn)題現(xiàn)場(chǎng)** 對(duì)于面向?qū)ο笳Z(yǔ)言來(lái)講，抽象層級(jí)特別的重要。尤其是對(duì)接口的抽象，它在設(shè)計(jì)和開(kāi)發(fā)中占很大的比重，我們?cè)陂_(kāi)發(fā)時(shí)希望盡量面向接口編程。 對(duì)于以上描述的接口方法來(lái)看，大概可以推斷出可能它包含了以下兩個(gè)含義: - listUser(): 查詢用戶列表 - get(Integerid): 查詢單個(gè)用戶 在所有的開(kāi)發(fā)中，XP推崇的TDD模式可以很好的引導(dǎo)我們對(duì)接口的定義，所以我們將TDD作為開(kāi)發(fā)代碼的”推動(dòng)者”。 對(duì)于以上的接口，當(dāng)我們使用TDD進(jìn)行測(cè)試用例先行時(shí)，發(fā)現(xiàn)了潛在的問(wèn)題： - listUser() 如果沒(méi)有數(shù)據(jù)，那它是返回空集合還是null呢？ - get(Integerid) 如果沒(méi)有這個(gè)對(duì)象，是拋異常還是返回null呢？ **深入listUser研究** 我們先來(lái)討論 這段代碼返回是null,從我多年的開(kāi)發(fā)經(jīng)驗(yàn)來(lái)講，對(duì)于集合這樣返回值，最好不要返回null，因?yàn)槿绻祷亓薾ull，會(huì)給調(diào)用者帶來(lái)很多麻煩。你將會(huì)把這種調(diào)用風(fēng)險(xiǎn)交給調(diào)用者來(lái)控制。 如果調(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ìn)行優(yōu)化： 對(duì)于接口( ListlistUser())，它一定會(huì)返回List，即使沒(méi)有數(shù)據(jù)，它仍然會(huì)返回List（集合中沒(méi)有任何元素）; 通過(guò)以上的修改，我們成功的避免了有可能發(fā)生的空指針異常，這樣的寫(xiě)法更安全！ **深入研究get方法** 對(duì)于接口 我們把接口定義加上了說(shuō)明之后，調(diào)用者會(huì)看到，如果調(diào)用此接口，很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常。 這種方式可以在調(diào)用者調(diào)用接口的時(shí)候看到接口的定義，但是，這種方式是”弱提示”的！關(guān)注微信公眾號(hào)：互聯(lián)網(wǎng)架構(gòu)師，在后臺(tái)回復(fù)：2T，可以獲取我整理的教程，都是干貨。 如果調(diào)用者忽略了注釋，有可能就對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生了風(fēng)險(xiǎn)，這個(gè)風(fēng)險(xiǎn)有可能導(dǎo)致一個(gè)億！ 除了以上這種”弱提示”的方式，還有一種方式是，返回值是有可能為空的。那要怎么辦呢？ 我認(rèn)為我們需要增加一個(gè)接口，用來(lái)描述這種場(chǎng)景. 引入jdk8的Optional,或者使用guava的Optional.看如下定義: **深入入?yún)?* 通過(guò)上述的所有接口的描述，你能確定入?yún)d一定是必傳的嗎？我覺(jué)得答案應(yīng)該是：不能確定。除非接口的文檔注釋上加以說(shuō)明。 那如何約束入?yún)⒛? 推薦兩種方式： - 強(qiáng)制約束 - 文檔性約束（弱提示） 1.強(qiáng)制約束，我們可以通過(guò)jsr 303進(jìn)行嚴(yán)格的約束聲明： 當(dāng)然，這樣寫(xiě)，要配合AOP的操作進(jìn)行驗(yàn)證，但讓spring已經(jīng)提供了很好的集成方案，在此就不在贅述了。 2.文檔性約束 在很多時(shí)候，我們會(huì)遇到遺留代碼，對(duì)于遺留代碼，整體性改造的可能性很小。 我們更希望通過(guò)閱讀接口的實(shí)現(xiàn)，來(lái)進(jìn)行接口的說(shuō)明。 jsr 305規(guī)范，給了我們一個(gè)描述接口入?yún)⒌囊粋€(gè)方式(需要引入庫(kù) com.google.code.findbugs:jsr305): 可以使用注解: @Nullable @Nonnull @CheckForNull 進(jìn)行接口說(shuō)明。比如: **小結(jié)** 通過(guò) 空集合返回值,Optional,jsr 303，jsr 305這幾種方式，可以讓我們的代碼可讀性更強(qiáng)，出錯(cuò)率更低！ 空集合返回值 ：如果有集合這樣返回值時(shí)，除非真的有說(shuō)服自己的理由，否則，一定要返回空集合，而不是null Optional: 如果你的代碼是jdk8，就引入它！如果不是，則使用Guava的Optional,或者升級(jí)jdk版本！它很大程度的能增加了接口的可讀性！ jsr 303: 如果新的項(xiàng)目正在開(kāi)發(fā)，不防加上這個(gè)試試！一定有一種特別爽的感覺(jué)! jsr 305: 如果老的項(xiàng)目在你的手上，你可以嘗試的加上這種文檔型注解，有助于你后期的重構(gòu)，或者新功能增加了，對(duì)于老接口的理解! **空對(duì)象模式** 場(chǎng)景 來(lái)看一個(gè)DTO轉(zhuǎn)化的場(chǎng)景，對(duì)象: 優(yōu)化修改 這樣的數(shù)據(jù)轉(zhuǎn)化，可讀性非常差，每個(gè)字段的判斷，如果是空就設(shè)置為空字符串(“”) 換一種思維方式進(jìn)行思考，我們是拿到Person這個(gè)類的數(shù)據(jù)，然后進(jìn)行賦值操作(setXXX),其實(shí)是不關(guān)系Person的具體實(shí)現(xiàn)是誰(shuí)的。 那我們可以創(chuàng)建一個(gè)Person子類: 其中 getPerson()方法，可以用來(lái)根據(jù)業(yè)務(wù)邏輯獲取Person有可能的對(duì)象（對(duì)當(dāng)前例子來(lái)講，如果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ì)帶來(lái)代碼的復(fù)雜性。 對(duì)于上述代碼，還可以使用Optional進(jìn)行優(yōu)化。 Optional對(duì)空值的使用，我覺(jué)得更為貼切，它只適用于”是否存在”的場(chǎng)景。 如果只對(duì)控制的存在判斷，我建議使用Optional。 Optioanl的正確使用 Optional如此強(qiáng)大，它表達(dá)了計(jì)算機(jī)最原始的特性(0 or 1),那它如何正確的被使用呢! Optional不要作為參數(shù) 如果你寫(xiě)了一個(gè)public方法，這個(gè)方法規(guī)定了一些輸入?yún)?shù)，這些參數(shù)中有一些是可以傳入null的，那這時(shí)候是否可以使用Optional呢？ 給的建議是: 一定不要這樣使用! 舉個(gè)例子: 我覺(jué)得這樣的語(yǔ)義更強(qiáng)，并且更能滿足 軟件設(shè)計(jì)原則中的 “單一職責(zé)”。 如果你覺(jué)得你的入?yún)⒄娴挠斜匾赡軅鱪ull,那請(qǐng)使用jsr 303或者jsr 305進(jìn)行說(shuō)明和驗(yàn)證! 請(qǐng)記住! Optional不能作為入?yún)⒌膮?shù)! **Optional作為返回值** 當(dāng)個(gè)實(shí)體的返回 那Optioanl可以做為返回值嗎？ 其實(shí)它是非常滿足是否存在這個(gè)語(yǔ)義的。 你如說(shuō)，你要根據(jù)id獲取用戶信息，這個(gè)用戶有可能存在或者不存在。 你可以這樣使用: 這樣的返回結(jié)果，會(huì)讓調(diào)用者不知所措，是否我判斷Optional之后，還用進(jìn)行isEmpty的判斷呢？ 這樣帶來(lái)的返回值歧義！我認(rèn)為是沒(méi)有必要的。 我們要約定，對(duì)于List這種集合返回值，如果集合真的是null的，請(qǐng)返回空集合(Lists.newArrayList); **使用Optional變量** 如果有這樣的變量userOpt,請(qǐng)記住 ： - 一定不能直接使用get ，如果這樣用，就喪失了Optional本身的含義 （ 比如userOp.get() ） - 不要直接使用getOrThrow ,如果你有這樣的需求：獲取不到就拋異常。那就要考慮，是否是調(diào)用的接口設(shè)計(jì)的是否合理 **getter中的使用** 對(duì)于一個(gè)java bean,所有的屬性都有可能返回null,那是否需要改寫(xiě)所有的getter成為Optional類型呢？ 給大家的建議是，不要這樣濫用Optional. 即便 我java bean中的getter是符合Optional的，但是因?yàn)閖ava bean 太多了，這樣會(huì)導(dǎo)致你的代碼有50%以上進(jìn)行Optinal的判斷，這樣便污染了代碼。(我想說(shuō)，其實(shí)你的實(shí)體中的字段應(yīng)該都是由業(yè)務(wù)含義的，會(huì)認(rèn)真的思考過(guò)它存在的價(jià)值的，不能因?yàn)镺ptional的存在而濫用) 我們應(yīng)該更關(guān)注于業(yè)務(wù)，而不只是空值的判斷。 不要在getter中濫用Optional. **小結(jié)** 可以這樣總結(jié)Optional的使用： - 當(dāng)使用值為空的情況，并非源于錯(cuò)誤時(shí)，可以使用Optional! - Optional不要用于集合操作! - 不要濫用Optional,比如在java bean的getter中! >【云棲號(hào)在線課堂】每天都有產(chǎn)品技術(shù)專家分享！ > 課程地址：https://yqh.aliyun.com/zhibo > 立即加入社群，與專家面對(duì)面，及時(shí)了解課程最新動(dòng)態(tài)！ > 【云棲號(hào)在線課堂 社群】https://c.tb.cn/F3.Z8gvnK 原文發(fā)布時(shí)間：2020-07-09 本文作者：互聯(lián)網(wǎng)架構(gòu)師 本文來(lái)自：“(https://mp.weixin.qq.com/s/6dQqX6RXt4nkmoEqp4_eKg)”，了解相關(guān)信息可以關(guān)注“(https://mp.weixin.qq.com/s/6dQqX6RXt4nkmoEqp4_eKg)”