在筆者幾年的開發(fā)經驗中敛纲，經常看到項目中存在到處空值判斷的情況剂癌，這些判斷淤翔，會讓人覺得摸不著頭緒，它的出現(xiàn)很有可能和當前的業(yè)務邏輯并沒有關系佩谷。但它會讓你很頭疼旁壮。
有時候，更可怕的是系統(tǒng)因為這些空值的情況谐檀，會拋出空指針異常抡谐，導致業(yè)務系統(tǒng)發(fā)生問題。
此篇文章桐猬，我總結了幾種關于空值的處理手法麦撵，希望對讀者有幫助。
在這里小編建了一個前端學習交流扣扣群：1093794329溃肪，我自己整理的最新的前端資料和高級開發(fā)教程免胃，如果有想需要的，可以加群一起學習交流
業(yè)務中的空值
場景
存在一個UserSearchService用來提供用戶查詢的功能:
public interface UserSearchService{
List listUser();
User get(Integer id);
}
問題現(xiàn)場
對于面向對象語言來講惫撰，抽象層級特別的重要羔沙。尤其是對接口的抽象，它在設計和開發(fā)中占很大的比重厨钻，我們在開發(fā)時希望盡量面向接口編程扼雏。
對于以上描述的接口方法來看，大概可以推斷出可能它包含了以下兩個含義:
listUser(): 查詢用戶列表
get(Integer id): 查詢單個用戶
在所有的開發(fā)中莉撇，XP推崇的TDD模式可以很好的引導我們對接口的定義呢蛤，所以我們將TDD作為開發(fā)代碼的”推動者”惶傻。
對于以上的接口棍郎，當我們使用TDD進行測試用例先行時，發(fā)現(xiàn)了潛在的問題：
listUser() 如果沒有數(shù)據(jù)银室，那它是返回空集合還是null呢涂佃？
get(Integer id) 如果沒有這個對象励翼，是拋異常還是返回null呢？
深入listUser研究
我們先來討論
listUser()
這個接口辜荠，我經称В看到如下實現(xiàn):
public List listUser(){
List userList = userListRepostity.selectByExample(new UserExample());
if(CollectionUtils.isEmpty(userList)){//spring util工具類
return null;
}
return userList;
}
這段代碼返回是null,從我多年的開發(fā)經驗來講，對于集合這樣返回值伯病，最好不要返回null造烁，因為如果返回了null，會給調用者帶來很多麻煩午笛。你將會把這種調用風險交給調用者來控制惭蟋。
如果調用者是一個謹慎的人，他會進行是否為null的條件判斷药磺。如果他并非謹慎告组，或者他是一個面向接口編程的狂熱分子(當然，面向接口編程是正確的方向)癌佩，他會按照自己的理解去調用接口木缝，而不進行是否為null的條件判斷，如果這樣的話围辙，是非常危險的我碟，它很有可能出現(xiàn)空指針異常！
根據(jù)墨菲定律來判斷:“很有可能出現(xiàn)的問題姚建，在將來一定會出現(xiàn)!”
基于此怎囚，我們將它進行優(yōu)化:
public List listUser(){
List userList = userListRepostity.selectByExample(new UserExample());
if(CollectionUtils.isEmpty(userList)){
return Lists.newArrayList();//guava類庫提供的方式
}
return userList;
}
對于接口(List listUser())，它一定會返回List桥胞，即使沒有數(shù)據(jù)恳守，它仍然會返回List（集合中沒有任何元素）;
通過以上的修改，我們成功的避免了有可能發(fā)生的空指針異常贩虾，這樣的寫法更安全催烘！
深入研究get方法
對于接口
User get(Integer id)
你能看到的現(xiàn)象是，我給出id缎罢，它一定會給我返回User.但事實真的很有可能不是這樣的伊群。
我看到過的實現(xiàn):
public User get(Integer id){
return userRepository.selectByPrimaryKey(id);//從數(shù)據(jù)庫中通過id直接獲取實體對象
}
相信很多人也都會這樣寫。
通過代碼的時候得知它的返回值很有可能是null! 但我們通過的接口是分辨不出來的!
這個是個非常危險的事情策精。尤其對于調用者來說舰始！
我給出的建議是，需要在接口明明時補充文檔,比如對于異常的說明,使用注解@exception:
public interface UserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實體
* @exception UserNotFoundException
*/
User get(Integer id);
}
我們把接口定義加上了說明之后咽袜，調用者會看到丸卷，如果調用此接口，很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常询刹。
這種方式可以在調用者調用接口的時候看到接口的定義谜嫉，但是萎坷，這種方式是”弱提示”的！
如果調用者忽略了注釋沐兰，有可能就對業(yè)務系統(tǒng)產生了風險哆档，這個風險有可能導致一個億！
除了以上這種”弱提示”的方式住闯，還有一種方式是瓜浸，返回值是有可能為空的。那要怎么辦呢比原？
我認為我們需要增加一個接口斟叼，用來描述這種場景.
引入jdk8的Optional,或者使用guava的Optional.看如下定義:
public interface UserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實體,此實體有可能是缺省值
*/
Optional getOptional(Integer id);
}
Optional有兩個含義: 存在 or 缺省。
那么通過閱讀接口getOptional()春寿，我們可以很快的了解返回值的意圖朗涩，這個其實是我們想看到的，它去除了二義性绑改。
它的實現(xiàn)可以寫成:
public Optional getOptional(Integer id){
return Optional.ofNullable(userRepository.selectByPrimaryKey(id));
}
深入入參
通過上述的所有接口的描述谢床，你能確定入參id一定是必傳的嗎？我覺得答案應該是：不能確定厘线。除非接口的文檔注釋上加以說明识腿。
那如何約束入參呢?
我給大家推薦兩種方式：
強制約束
文檔性約束（弱提示）
1.強制約束，我們可以通過jsr 303進行嚴格的約束聲明:
public interface UserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實體
* @exception UserNotFoundException
*/
User get(@NotNull Integer id);
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實體,此實體有可能是缺省值
*/
Optional getOptional(@NotNull Integer id);
}
當然造壮，這樣寫渡讼，要配合AOP的操作進行驗證，但讓spring已經提供了很好的集成方案耳璧，在此我就不在贅述了成箫。
2.文檔性約束
在很多時候，我們會遇到遺留代碼旨枯，對于遺留代碼蹬昌，整體性改造的可能性很小。
我們更希望通過閱讀接口的實現(xiàn)攀隔，來進行接口的說明皂贩。
jsr 305規(guī)范，給了我們一個描述接口入參的一個方式(需要引入庫 com.google.code.findbugs:jsr305):
可以使用注解: @Nullable @Nonnull @CheckForNull 進行接口說明昆汹。比如:
public interface UserSearchService{
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實體
* @exception UserNotFoundException
*/
@CheckForNull
User get(@NonNull Integer id);
/**
* 根據(jù)用戶id獲取用戶信息
* @param id 用戶id
* @return 用戶實體,此實體有可能是缺省值
*/
Optional getOptional(@NonNull Integer id);
}
小結
通過 空集合返回值,Optional,jsr 303明刷，jsr 305這幾種方式，可以讓我們的代碼可讀性更強满粗，出錯率更低辈末！
空集合返回值 ：如果有集合這樣返回值時，除非真的有說服自己的理由，否則本冲，一定要返回空集合，而不是null
Optional: 如果你的代碼是jdk8劫扒，就引入它檬洞！如果不是，則使用Guava的Optional,或者升級jdk版本沟饥！它很大程度的能增加了接口的可讀性添怔！
jsr 303: 如果新的項目正在開發(fā)，不防加上這個試試贤旷！一定有一種特別爽的感覺!
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("");
}
}
優(yōu)化修改
這樣的數(shù)據(jù)轉化缭贡，我們認識可讀性非常差，每個字段的判斷辉懒，如果是空就設置為空字符串(“”)
換一種思維方式進行思考阳惹，我們是拿到Person這個類的數(shù)據(jù)，然后進行賦值操作(setXXX),其實是不關系Person的具體實現(xiàn)是誰的眶俩。
那我們可以創(chuàng)建一個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()方法仿便，可以用來根據(jù)業(yè)務邏輯獲取Person有可能的對象（對當前例子來講体啰，如果Person不存在，返回Person的的特例NUllPerson）嗽仪，如果修改成這樣荒勇，代碼的可讀性就會變的很強了。
使用Optional可以進行優(yōu)化
空對象模式闻坚，它的弊端在于需要創(chuàng)建一個特例對象沽翔，但是如果特例的情況比較多，我們是不是需要創(chuàng)建多個特例對象呢，雖然我們也使用了面向對象的多態(tài)特性仅偎，但是跨蟹，業(yè)務的復雜性如果真的讓我們創(chuàng)建多個特例對象，我們還是要再三考慮一下這種模式橘沥，它可能會帶來代碼的復雜性窗轩。
對于上述代碼，還可以使用Optional進行優(yōu)化座咆。
@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不要作為參數(shù)
如果你寫了一個public方法哺呜，這個方法規(guī)定了一些輸入參數(shù)舌缤，這些參數(shù)中有一些是可以傳入null的，那這時候是否可以使用Optional呢某残？
我給的建議是: 一定不要這樣使用!
舉個例子:
public interface UserService{
List listUser(Optional username);
}
這個例子的方法 listUser,可能在告訴我們需要根據(jù)username查詢所有數(shù)據(jù)集合友驮，如果username是空，也要返回所有的用戶集合.
當我們看到這個方法的時候驾锰，會覺得有一些歧義:
“如果username是absent,是返回空集合嗎卸留？還是返回全部的用戶數(shù)據(jù)集合？”
Optioanl是一種分支的判斷椭豫，那我們究竟是關注 Optional還是Optional.get()呢耻瑟？
我給大家的建議是，如果不想要這樣的歧義赏酥，就不要使用它喳整！
如果你真的想表達兩個含義，就給它拆分出兩個接口:
public interface UserService{
List listUser(String username);
List listUser();
}
我覺得這樣的語義更強裸扶，并且更能滿足 軟件設計原則中的 “單一職責”框都。
如果你覺得你的入參真的有必要可能傳null,那請使用jsr 303或者jsr 305進行說明和驗證!
請記住! Optional不能作為入參的參數(shù)!
Optional作為返回值
當個實體的返回
那Optioanl可以做為返回值嗎？
其實它是非常滿足是否存在這個語義的呵晨。
你如說魏保，你要根據(jù)id獲取用戶信息，這個用戶有可能存在或者不存在摸屠。
你可以這樣使用:
public interface UserService{
Optional get(Integer id);
}
當調用這個方法的時候谓罗，調用者很清楚get方法返回的數(shù)據(jù)，有可能不存在季二，這樣可以做一些更合理的判斷檩咱，更好的防止空指針的錯誤揭措！
當然，如果業(yè)務方真的需要根據(jù)id必須查詢出User的話刻蚯，就不要這樣使用了绊含，請說明，你要拋出的異常.
只有當考慮它返回null是合理的情況下炊汹，才進行Optional的返回
集合實體的返回
不是所有的返回值都可以這樣用的躬充！如果你返回的是集合：
public interface UserService{
Optional> listUser();
}
這樣的返回結果，會讓調用者不知所措兵扬，是否我判斷Optional之后麻裳，還用進行isEmpty的判斷呢口蝠？
這樣帶來的返回值歧義器钟！我認為是沒有必要的。
我們要約定妙蔗，對于List這種集合返回值傲霸，如果集合真的是null的，請返回空集合(Lists.newArrayList);
使用Optional變量
Optional userOpt = ...
如果有這樣的變量userOpt,請記住 ：
一定不能直接使用get 眉反，如果這樣用昙啄，就喪失了Optional本身的含義 （ 比如userOp.get() ）
不要直接使用getOrThrow ,如果你有這樣的需求：獲取不到就拋異常。那就要考慮寸五，是否是調用的接口設計的是否合理
getter中的使用
對于一個java bean,所有的屬性都有可能返回null,那是否需要改寫所有的getter成為Optional類型呢梳凛？
我給大家的建議是，不要這樣濫用Optional.
即便 我java bean中的getter是符合Optional的梳杏，但是因為java bean 太多了韧拒，這樣會導致你的代碼有50%以上進行Optinal的判斷，這樣便污染了代碼十性。(我想說叛溢，其實你的實體中的字段應該都是由業(yè)務含義的，會認真的思考過它存在的價值的劲适，不能因為Optional的存在而濫用)
我們應該更關注于業(yè)務楷掉，而不只是空值的判斷。
請不要在getter中濫用Optional.
小結
可以這樣總結Optional的使用：
當使用值為空的情況霞势，并非源于錯誤時烹植，可以使用Optional!
Optional不要用于集合操作!
不要濫用Optional,比如在java bean的getter中!
