來源：西格瑪的博客
https://lrwinx.github.io/
2019-12-17 09:39:00
在筆者幾年的開發經驗中，經常看到專案中存在到處空值判斷的情況，這些判斷，會讓人覺得摸不著頭緒，它的出現很有可能和當前的業務邏輯并沒有關系，但它會讓你很頭疼，
有時候，更可怕的是系統因為這些空值的情況，會拋出空指標例外，導致業務系統發生問題，
此篇文章，我總結了幾種關于空值的處理手法，希望對讀者有幫助，
業務中的空值
場景
存在一個UserSearchService用來提供用戶查詢的功能:
public interface UserSearchService{
List<User> listUser();
User get(Integer id);
}
問題現場
對于面向物件語言來講，抽象層級特別的重要，尤其是對介面的抽象，它在設計和開發中占很大的比重，我們在開發時希望盡量面向介面編程，
對于以上描述的介面方法來看，大概可以推斷出可能它包含了以下兩個含義:
-
listUser(): 查詢用戶串列
-
get(Integer id): 查詢單個用戶
在所有的開發中，XP推崇的TDD模式可以很好的引導我們對介面的定義，所以我們將TDD作為開發代碼的”推動者”，
對于以上的介面，當我們使用TDD進行測驗用例先行時，發現了潛在的問題：
-
listUser() 如果沒有資料，那它是回傳空集合還是null呢？
-
get(Integer id) 如果沒有這個物件，是拋例外還是回傳null呢？
深入listUser研究
我們先來討論
listUser()
這個介面，我經常看到如下實作:
public List<User> listUser(){
List<User> userList = userListRepostity.selectByExample(new UserExample());
if(CollectionUtils.isEmpty(userList)){//spring util工具類
return null;
}
return userList;
}
這段代碼回傳是null,從我多年的開發經驗來講，對于集合這樣回傳值，最好不要回傳null，因為如果回傳了null，會給呼叫者帶來很多麻煩，你將會把這種呼叫風險交給呼叫者來控制，
如果呼叫者是一個謹慎的人，他會進行是否為null的條件判斷，如果他并非謹慎，或者他是一個面向介面編程的狂熱分子(當然，面向介面編程是正確的方向)，他會按照自己的理解去呼叫介面，而不進行是否為null的條件判斷，如果這樣的話，是非常危險的，它很有可能出現空指標例外！
根據墨菲定律來判斷: “很有可能出現的問題，在將來一定會出現!”
基于此，我們將它進行優化:
public List<User> listUser(){
List<User> userList = userListRepostity.selectByExample(new UserExample());
if(CollectionUtils.isEmpty(userList)){
return Lists.newArrayList();//guava類別庫提供的方式
}
return userList;
}
對于介面(List listUser())，它一定會回傳List，即使沒有資料，它仍然會回傳List（集合中沒有任何元素）;
通過以上的修改，我們成功的避免了有可能發生的空指標例外，這樣的寫法更安全！
深入研究get方法
對于介面
User get(Integer id)
你能看到的現象是，我給出id，它一定會給我回傳User.但事實真的很有可能不是這樣的，
我看到過的實作:
public User get(Integer id){
return userRepository.selectByPrimaryKey(id);//從資料庫中通過id直接獲取物體物件
}
相信很多人也都會這樣寫，
通過代碼的時候得知它的回傳值很有可能是null! 但我們通過的介面是分辨不出來的!
這個是個非常危險的事情，尤其對于呼叫者來說！
我給出的建議是，需要在介面明明時補充檔案,比如對于例外的說明,使用注解@exception:
public interface UserSearchService{
/**
* 根據用戶id獲取用戶資訊
* @param id 用戶id
* @return 用戶物體
* @exception UserNotFoundException
*/
User get(Integer id);
}
我們把介面定義加上了說明之后，呼叫者會看到，如果呼叫此介面，很有可能拋出“UserNotFoundException(找不到用戶)”這樣的例外，
這種方式可以在呼叫者呼叫介面的時候看到介面的定義，但是，這種方式是”弱提示”的！
如果呼叫者忽略了注釋，有可能就對業務系統產生了風險，這個風險有可能導致一個億！
除了以上這種”弱提示”的方式，還有一種方式是，回傳值是有可能為空的，****那要怎么辦呢？
我認為我們需要增加一個介面，用來描述這種場景.
引入jdk8的Optional,或者使用guava的Optional.看如下定義:
public interface UserSearchService{
/**
* 根據用戶id獲取用戶資訊
* @param id 用戶id
* @return 用戶物體,此物體有可能是預設值
*/
Optional<User> getOptional(Integer id);
}
Optional有兩個含義: 存在 or 預設，
那么通過閱讀介面getOptional()，我們可以很快的了解回傳值的意圖，這個其實是我們想看到的，它去除了二義性，
它的實作可以寫成:
public Optional<User> getOptional(Integer id){
return Optional.ofNullable(userRepository.selectByPrimaryKey(id));
}
深入入參
通過上述的所有介面的描述，你能確定入參id一定是必傳的嗎？我覺得答案應該是：不能確定，除非介面的檔案注釋上加以說明，
那如何約束入參呢?
我給大家推薦兩種方式：
-
強制約束
-
檔案性約束（弱提示）
1.強制約束，我們可以通過jsr 303進行嚴格的約束宣告:
public interface UserSearchService{
/**
* 根據用戶id獲取用戶資訊
* @param id 用戶id
* @return 用戶物體
* @exception UserNotFoundException
*/
User get(@NotNull Integer id);
/**
* 根據用戶id獲取用戶資訊
* @param id 用戶id
* @return 用戶物體,此物體有可能是預設值
*/
Optional<User> getOptional(@NotNull Integer id);
}
當然，這樣寫，要配合AOP的操作進行驗證，但讓spring已經提供了很好的集成方案，在此我就不在贅述了，關注微信公眾號：Java技術堆疊，在后臺回復：spring，可以獲取我整理的 N 篇最新 Spring 系列教程，都是干貨，
2.檔案性約束
在很多時候，我們會遇到遺留代碼，對于遺留代碼，整體性改造的可能性很小，
我們更希望通過閱讀介面的實作，來進行介面的說明，
jsr 305規范，給了我們一個描述介面入參的一個方式(需要引入庫 com.google.code.findbugs:jsr305):
可以使用注解: @Nullable @Nonnull @CheckForNull 進行介面說明，
比如:
public interface UserSearchService{
/**
* 根據用戶id獲取用戶資訊
* @param id 用戶id
* @return 用戶物體
* @exception UserNotFoundException
*/
@CheckForNull
User get(@NonNull Integer id);
/**
* 根據用戶id獲取用戶資訊
* @param id 用戶id
* @return 用戶物體,此物體有可能是預設值
*/
Optional<User> getOptional(@NonNull Integer id);
}
小結
通過 空集合回傳值,Optional,jsr 303，jsr 305這幾種方式，可以讓我們的代碼可讀性更強，出錯率更低！
-
空集合回傳值 ：如果有集合這樣回傳值時，除非真的有說服自己的理由，否則，一定要回傳空集合，而不是null
-
Optional: 如果你的代碼是jdk8，就引入它！如果不是，則使用Guava的Optional,或者升級jdk版本！它很大程度的能增加了介面的可讀性！
-
jsr 303: 如果新的專案正在開發，不防加上這個試試！一定有一種特別爽的感覺!
-
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("");
}
}
優化修改
這樣的資料轉化，我們認識可讀性非常差，每個欄位的判斷，如果是空就設定為空字串(“”)
換一種思維方式進行思考，我們是拿到Person這個類的資料，然后進行賦值操作(setXXX),其實是不關系Person的具體實作是誰的，
那我們可以創建一個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()方法，可以用來根據業務邏輯獲取Person有可能的物件（對當前例子來講，如果Person不存在，回傳Person的的特例NUllPerson），如果修改成這樣，代碼的可讀性就會變的很強了，
使用Optional可以進行優化
空物件模式，它的弊端在于需要創建一個特例物件，但是如果特例的情況比較多，我們是不是需要創建多個特例物件呢，雖然我們也使用了面向物件的多型特性，但是，業務的復雜性如果真的讓我們創建多個特例物件，我們還是要再三考慮一下這種模式，它可能會帶來代碼的復雜性，
對于上述代碼，還可以使用Optional進行優化，
@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不要作為引數
如果你寫了一個public方法，這個方法規定了一些輸入引數，這些引數中有一些是可以傳入null的，那這時候是否可以使用Optional呢？
我給的建議是: 一定不要這樣使用!
舉個例子:
public interface UserService{
List<User> listUser(Optional<String> username);
}
這個例子的方法 listUser,可能在告訴我們需要根據username查詢所有資料集合，如果username是空，也要回傳所有的用戶集合.
當我們看到這個方法的時候，會覺得有一些歧義:
“如果username是absent,是回傳空集合嗎？還是回傳全部的用戶資料集合？”
Optional是一種分支的判斷，那我們究竟是關注 Optional還是Optional.get()呢？
我給大家的建議是，如果不想要這樣的歧義，就不要使用它！
如果你真的想表達兩個含義，就給它拆分出兩個介面:
public interface UserService{
List<User> listUser(String username);
List<User> listUser();
}
我覺得這樣的語意更強，并且更能滿足 軟體設計原則中的 “單一職責”，
如果你覺得你的入參真的有必要可能傳null,那請使用jsr 303或者jsr 305進行說明和驗證!
請記住! Optional不能作為入參的引數!
**
Optional作為回傳值**
當個物體的回傳
那Optional可以做為回傳值嗎？
其實它是非常滿足是否存在這個語意的，
你如說，你要根據id獲取用戶資訊，這個用戶有可能存在或者不存在，
你可以這樣使用:
public interface UserService{
Optional<User> get(Integer id);
}
當呼叫這個方法的時候，呼叫者很清楚get方法回傳的資料，有可能不存在，這樣可以做一些更合理的判斷，更好的防止空指標的錯誤！
當然，如果業務方真的需要根據id必須查詢出User的話，就不要這樣使用了，請說明，你要拋出的例外.
只有當考慮它回傳null是合理的情況下，才進行Optional的回傳
集合物體的回傳
不是所有的回傳值都可以這樣用的！如果你回傳的是集合：
public interface UserService{
Optional<List<User>> listUser();
}
這樣的回傳結果，會讓呼叫者不知所措，是否我判斷Optional之后，還用進行isEmpty的判斷呢？
這樣帶來的回傳值歧義！我認為是沒有必要的，
我們要約定，對于List這種集合回傳值，如果集合真的是null的，請回傳空集合(Lists.newArrayList);
使用Optional變數
Optional<User> userOpt = ...
如果有這樣的變數userOpt,請記住 ：
-
一定不能直接使用get ，如果這樣用，就喪失了Optional本身的含義 （ 比如userOp.get() ）
-
不要直接使用getOrThrow ,如果你有這樣的需求：獲取不到就拋例外，那就要考慮，是否是呼叫的介面設計的是否合理
getter中的使用
對于一個java bean,所有的屬性都有可能回傳null,那是否需要改寫所有的getter成為Optional型別呢？
我給大家的建議是，不要這樣濫用Optional.
即便 我java bean中的getter是符合Optional的，但是因為java bean 太多了，這樣會導致你的代碼有50%以上進行Optional的判斷，這樣便污染了代碼，(我想說，其實你的物體中的欄位應該都是由業務含義的，會認真的思考過它存在的價值的，不能因為Optional的存在而濫用)
我們應該更關注于業務，而不只是空值的判斷，
請不要在getter中濫用Optional.
小結
可以這樣總結Optional的使用：
-
當使用值為空的情況，并非源于錯誤時，可以使用Optional
-
Optional不要用于集合操作!
-
不要濫用Optional,比如在java bean的getter中!
近期熱文推薦：
1.Java 15 正式發布， 14 個新特性，重繪你的認知！！
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，
4.吊打 Tomcat ，Undertow 性能很炸！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/183847.html
標籤：Java