处理入参_看看优秀的程序员是如何处理NPE的
點(diǎn)擊上方?果汁簡歷?，選擇“置頂公眾號”
優(yōu)質(zhì)文章，第一時(shí)間送達(dá)
西格瑪?shù)牟┛?/p>
https://urlify.cn/7j2uMz
在筆者幾年的開發(fā)經(jīng)驗(yàn)中，經(jīng)常看到項(xiàng)目中存在到處空值判斷的情況，這些判斷，會讓人覺得摸不這頭緒，它的出現(xiàn)很有可能和當(dāng)前的業(yè)務(wù)邏輯并沒有關(guān)系。但它會讓你很頭疼。
有時(shí)候，更可怕的是系統(tǒng)因?yàn)檫@些空值的情況，會拋出空指針異常，導(dǎo)致業(yè)務(wù)系統(tǒng)發(fā)生問題。
此篇文章，我總結(jié)了幾種關(guān)于空值的處理手法，希望對讀者有幫助。
場景
存在一個(gè) UserSearchService 用來提供用戶查詢的功能:
publicinterfaceUserSearchService{
List<User> listUser();
Userget(Integer id);
}
問題現(xiàn)場
對于面向?qū)ο笳Z言來講，抽象層級特別的重要。尤其是對接口的抽象，它在設(shè)計(jì)和開發(fā)中占很大的比重，我們在開發(fā)時(shí)希望盡量面向接口編程。
對于以上描述的接口方法來看，大概可以推斷出可能它包含了以下兩個(gè)含義:
listUser(): 查詢用戶列表
get(Integer id): 查詢單個(gè)用戶
在所有的開發(fā)中，XP 推崇的 TDD 模式可以很好的引導(dǎo)我們對接口的定義，所以我們將 TDD 作為開發(fā)代碼的” 推動者”。
對于以上的接口，當(dāng)我們使用 TDD 進(jìn)行測試用例先行時(shí)，發(fā)現(xiàn)了潛在的問題：
listUser() 如果沒有數(shù)據(jù)，那它是返回空集合還是 null 呢？
get(Integer id) 如果沒有這個(gè)對象，是拋異常還是返回 null 呢？
深入 listUser 研究
我們先來討論
listUser()
這個(gè)接口，我經(jīng)常看到如下實(shí)現(xiàn):
publicList<User> listUser(){
List<User> userList = userListRepostity.selectByExample(newUserExample());
if(CollectionUtils.isEmpty(userList)){//spring util工具類
returnnull;
}
return userList;
}
這段代碼返回是 null, 從我多年的開發(fā)經(jīng)驗(yàn)來講，對于集合這樣返回值，最好不要返回 null，因?yàn)槿绻祷亓?null，會給調(diào)用者帶來很多麻煩。你將會把這種調(diào)用風(fēng)險(xiǎn)交給調(diào)用者來控制。
如果調(diào)用者是一個(gè)謹(jǐn)慎的人，他會進(jìn)行是否為 null 的條件判斷。如果他并非謹(jǐn)慎，或者他是一個(gè)面向接口編程的狂熱分子 (當(dāng)然，面向接口編程是正確的方向)，他會按照自己的理解去調(diào)用接口，而不進(jìn)行是否為 null 的條件判斷，如果這樣的話，是非常危險(xiǎn)的，它很有可能出現(xiàn)空指針異常！
根據(jù)墨菲定律來判斷: “很有可能出現(xiàn)的問題，在將來一定會出現(xiàn)!”
基于此，我們將它進(jìn)行優(yōu)化:
publicList<User> listUser(){
List<User> userList = userListRepostity.selectByExample(newUserExample());
if(CollectionUtils.isEmpty(userList)){
returnLists.newArrayList();//guava類庫提供的方式
}
return userList;
}
對于接口 (List listUser())，它一定會返回 List，即使沒有數(shù)據(jù)，它仍然會返回 List(集合中沒有任何元素);
通過以上的修改，我們成功的避免了有可能發(fā)生的空指針異常，這樣的寫法更安全！
深入研究 get 方法
對于接口
Userget(Integer id)
你能看到的現(xiàn)象是，我給出 id，它一定會給我返回 User. 但事實(shí)真的很有可能不是這樣的。
我看到過的實(shí)現(xiàn):
publicUserget(Integer id){
return userRepository.selectByPrimaryKey(id);//從數(shù)據(jù)庫中通過id直接獲取實(shí)體對象
}
相信很多人也都會這樣寫。
通過代碼的時(shí)候得知它的返回值很有可能是 null! 但我們通過的接口是分辨不出來的!
這個(gè)是個(gè)非常危險(xiǎn)的事情。尤其對于調(diào)用者來說！
我給出的建議是，需要在接口明明時(shí)補(bǔ)充文檔, 比如對于異常的說明, 使用注解 @exception:
publicinterfaceUserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實(shí)體
* @exception UserNotFoundException
*/
Userget(Integer id);
}
我們把接口定義加上了說明之后，調(diào)用者會看到，如果調(diào)用此接口，很有可能拋出 “UserNotFoundException(找不到用戶)” 這樣的異常。
這種方式可以在調(diào)用者調(diào)用接口的時(shí)候看到接口的定義，但是，這種方式是” 弱提示” 的！
如果調(diào)用者忽略了注釋，有可能就對業(yè)務(wù)系統(tǒng)產(chǎn)生了風(fēng)險(xiǎn)，這個(gè)風(fēng)險(xiǎn)有可能導(dǎo)致一個(gè)億！
除了以上這種” 弱提示” 的方式，還有一種方式是，返回值是有可能為空的。那要怎么辦呢？
我認(rèn)為我們需要增加一個(gè)接口，用來描述這種場景.
引入 jdk8 的 Optional, 或者使用 guava 的 Optional. 看如下定義:
publicinterfaceUserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實(shí)體,此實(shí)體有可能是缺省值
*/
Optional<User> getOptional(Integer id);
}
Optional 有兩個(gè)含義: 存在 or 缺省。
那么通過閱讀接口 getOptional()，我們可以很快的了解返回值的意圖，這個(gè)其實(shí)是我們想看到的，它去除了二義性。
它的實(shí)現(xiàn)可以寫成:
publicOptional<User> getOptional(Integer id){
returnOptional.ofNullable(userRepository.selectByPrimaryKey(id));
}
深入入?yún)?/h3>
通過上述的所有接口的描述，你能確定入?yún)?id 一定是必傳的嗎？我覺得答案應(yīng)該是：不能確定。除非接口的文檔注釋上加以說明。
那如何約束入?yún)⒛?
我給大家推薦兩種方式：
強(qiáng)制約束
文檔性約束(弱提示)
強(qiáng)制約束，我們可以通過 jsr 303 進(jìn)行嚴(yán)格的約束聲明:
publicinterfaceUserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實(shí)體
* @exception UserNotFoundException
*/
Userget(@NotNullInteger id);
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實(shí)體,此實(shí)體有可能是缺省值
*/
Optional<User> getOptional(@NotNullInteger id);
}
當(dāng)然，這樣寫，要配合 AOP 的操作進(jìn)行驗(yàn)證，但讓 spring 已經(jīng)提供了很好的集成方案，在此我就不在贅述了。
文檔性約束
在很多時(shí)候，我們會遇到遺留代碼，對于遺留代碼，整體性改造的可能性很小。
我們更希望通過閱讀接口的實(shí)現(xiàn)，來進(jìn)行接口的說明。
jsr 305 規(guī)范，給了我們一個(gè)描述接口入?yún)⒌囊粋€(gè)方式 (需要引入庫 com.google.code.findbugs:jsr305):
可以使用注解: @Nullable @Nonnull @CheckForNull 進(jìn)行接口說明。
比如:
publicinterfaceUserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實(shí)體
* @exception UserNotFoundException
*/
@CheckForNull
Userget(@NonNullInteger id);
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實(shí)體,此實(shí)體有可能是缺省值
*/
Optional<User> getOptional(@NonNullInteger id);
}
小結(jié)
通過 空集合返回值, Optional,jsr 303，jsr 305 這幾種方式，可以讓我們的代碼可讀性更強(qiáng)，出錯(cuò)率更低！
空集合返回值 ：如果有集合這樣返回值時(shí)，除非真的有說服自己的理由，否則，一定要返回空集合，而不是 null
Optional: 如果你的代碼是 jdk8，就引入它！如果不是，則使用 Guava 的 Optional, 或者升級 jdk 版本！它很大程度的能增加了接口的可讀性！
jsr 303: 如果新的項(xiàng)目正在開發(fā)，不防加上這個(gè)試試！一定有一種特別爽的感覺!
jsr 305: 如果老的項(xiàng)目在你的手上，你可以嘗試的加上這種文檔型注解，有助于你后期的重構(gòu)，或者新功能增加了，對于老接口的理解!
場景
我們來看一個(gè) DTO 轉(zhuǎn)化的場景，對象:
@Data
staticclassPersonDTO{
privateString dtoName;
privateString dtoAge;
}
@Data
staticclassPerson{
privateString name;
privateString age;
}
需求是將 Person 對象轉(zhuǎn)化成 PersonDTO，然后進(jìn)行返回。
當(dāng)然對于實(shí)際操作來講，返回如果 Person 為空，將返回 null, 但是 PersonDTO 是不能返回 null 的(尤其 Rest 接口返回的這種 DTO)。
在這里，我們只關(guān)注轉(zhuǎn)化操作，看如下代碼:
@Test
publicvoid shouldConvertDTO(){
PersonDTO personDTO = newPersonDTO();
Person person = newPerson();
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)識可讀性非常差，每個(gè)字段的判斷，如果是空就設(shè)置為空字符串 (“”)
換一種思維方式進(jìn)行思考，我們是拿到 Person 這個(gè)類的數(shù)據(jù)，然后進(jìn)行賦值操作 (setXXX), 其實(shí)是不關(guān)系 Person 的具體實(shí)現(xiàn)是誰的。
那我們可以創(chuàng)建一個(gè) Person 子類:
staticclassNullPersonextendsPerson{
@Override
publicString getAge() {
return"";
}
@Override
publicString getName() {
return"";
}
}
它作為 Person 的一種特例而存在，如果當(dāng) Person 為空的時(shí)候，則返回一些 get * 的默認(rèn)行為.
所以代碼可以修改為:
@Test
publicvoid shouldConvertDTO(){
PersonDTO personDTO = newPersonDTO();
Person person = getPerson();
personDTO.setDtoAge(person.getAge());
personDTO.setDtoName(person.getName());
}
privatePerson getPerson(){
returnnewNullPerson();//如果Person是null ,則返回空對象
}
其中 getPerson() 方法，可以用來根據(jù)業(yè)務(wù)邏輯獲取 Person 有可能的對象(對當(dāng)前例子來講，如果 Person 不存在，返回 Person 的的特例 NUllPerson)，如果修改成這樣，代碼的可讀性就會變的很強(qiáng)了。
使用 Optional 可以進(jìn)行優(yōu)化
空對象模式，它的弊端在于需要?jiǎng)?chuàng)建一個(gè)特例對象，但是如果特例的情況比較多，我們是不是需要?jiǎng)?chuàng)建多個(gè)特例對象呢，雖然我們也使用了面向?qū)ο蟮亩鄳B(tài)特性，但是，業(yè)務(wù)的復(fù)雜性如果真的讓我們創(chuàng)建多個(gè)特例對象，我們還是要再三考慮一下這種模式，它可能會帶來代碼的復(fù)雜性。
對于上述代碼，還可以使用 Optional 進(jìn)行優(yōu)化。
@Test
publicvoid shouldConvertDTO(){
PersonDTO personDTO = newPersonDTO();
Optional.ofNullable(getPerson()).ifPresent(person -> {
personDTO.setDtoAge(person.getAge());
personDTO.setDtoName(person.getName());
});
}
privatePerson getPerson(){
returnnull;
}
Optional 對空值的使用，我覺得更為貼切，它只適用于” 是否存在” 的場景。
如果只對控制的存在判斷，我建議使用 Optional.
Optional 如此強(qiáng)大，它表達(dá)了計(jì)算機(jī)最原始的特性 (0 or 1), 那它如何正確的被使用呢!
Optional 不要作為參數(shù)
如果你寫了一個(gè) public 方法，這個(gè)方法規(guī)定了一些輸入?yún)?shù)，這些參數(shù)中有一些是可以傳入 null 的，那這時(shí)候是否可以使用 Optional 呢？
我給的建議是: 一定不要這樣使用!
舉個(gè)例子:
publicinterfaceUserService{
List<User> listUser(Optional<String> username);
}
這個(gè)例子的方法 listUser, 可能在告訴我們需要根據(jù) username 查詢所有數(shù)據(jù)集合，如果 username 是空，也要返回所有的用戶集合.
當(dāng)我們看到這個(gè)方法的時(shí)候，會覺得有一些歧義:
“如果 username 是 absent, 是返回空集合嗎？還是返回全部的用戶數(shù)據(jù)集合？”
Optioanl 是一種分支的判斷，那我們究竟是關(guān)注 Optional 還是 Optional.get() 呢？
我給大家的建議是，如果不想要這樣的歧義，就不要使用它！
如果你真的想表達(dá)兩個(gè)含義，就給它拆分出兩個(gè)接口:
publicinterfaceUserService{
List<User> listUser(String username);
List<User> listUser();
}
我覺得這樣的語義更強(qiáng)，并且更能滿足 軟件設(shè)計(jì)原則中的 “單一職責(zé)”。
如果你覺得你的入?yún)⒄娴挠斜匾赡軅?null, 那請使用 jsr 303 或者 jsr 305 進(jìn)行說明和驗(yàn)證!
請記住! Optional 不能作為入?yún)⒌膮?shù)!
Optional 作為返回值
當(dāng)個(gè)實(shí)體的返回
那 Optioanl 可以做為返回值嗎？
其實(shí)它是非常滿足是否存在這個(gè)語義的。
你如說，你要根據(jù) id 獲取用戶信息，這個(gè)用戶有可能存在或者不存在。
你可以這樣使用:
publicinterfaceUserService{
Optional<User> get(Integer id);
}
當(dāng)調(diào)用這個(gè)方法的時(shí)候，調(diào)用者很清楚 get 方法返回的數(shù)據(jù)，有可能不存在，這樣可以做一些更合理的判斷，更好的防止空指針的錯(cuò)誤！
當(dāng)然，如果業(yè)務(wù)方真的需要根據(jù) id 必須查詢出 User 的話，就不要這樣使用了，請說明，你要拋出的異常.
只有當(dāng)考慮它返回 null 是合理的情況下，才進(jìn)行 Optional 的返回
集合實(shí)體的返回
不是所有的返回值都可以這樣用的！如果你返回的是集合：
publicinterfaceUserService{
Optional<List<User>> listUser();
}
這樣的返回結(jié)果，會讓調(diào)用者不知所措，是否我判斷 Optional 之后，還用進(jìn)行 isEmpty 的判斷呢？
這樣帶來的返回值歧義！我認(rèn)為是沒有必要的。
我們要約定，對于 List 這種集合返回值，如果集合真的是 null 的，請返回空集合 (Lists.newArrayList);
使用 Optional 變量
Optional<User> userOpt = ...
如果有這樣的變量 userOpt, 請記住 ：
一定不能直接使用 get ，如果這樣用，就喪失了 Optional 本身的含義 ( 比如 userOp.get() )
不要直接使用 getOrThrow , 如果你有這樣的需求：獲取不到就拋異常。那就要考慮，是否是調(diào)用的接口設(shè)計(jì)的是否合理
getter 中的使用
對于一個(gè) java bean, 所有的屬性都有可能返回 null, 那是否需要改寫所有的 getter 成為 Optional 類型呢？
我給大家的建議是，不要這樣濫用 Optional.
即便 我 java bean 中的 getter 是符合 Optional 的，但是因?yàn)?java bean 太多了，這樣會導(dǎo)致你的代碼有 50% 以上進(jìn)行 Optinal 的判斷，這樣便污染了代碼。(我想說，其實(shí)你的實(shí)體中的字段應(yīng)該都是由業(yè)務(wù)含義的，會認(rèn)真的思考過它存在的價(jià)值的，不能因?yàn)?Optional 的存在而濫用)
我們應(yīng)該更關(guān)注于業(yè)務(wù)，而不只是空值的判斷。
請不要在 getter 中濫用 Optional.
小結(jié)
可以這樣總結(jié) Optional 的使用：
當(dāng)使用值為空的情況，并非源于錯(cuò)誤時(shí)，可以使用 Optional!
Optional 不要用于集合操作!
不要濫用 Optional, 比如在 java bean 的 getter 中!
點(diǎn)個(gè)贊唄
總結(jié)
以上是生活随笔為你收集整理的处理入参_看看优秀的程序员是如何处理NPE的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vm客户机隔离不能选_开汽车美容店，这些
- 下一篇： 2019计算机组成原理及答案,2019计