如何優雅地根治 null 值引起的 Bug，看我的！
寫在前面
在筆者幾年的開發經驗中，經常看到專案中存在到處
空值判斷
的情況，這些判斷，會讓人覺得摸不著頭緒，它的出現很有可能和當前的業務邏輯並沒有關係。但它會讓你很頭疼。
有時候，更可怕的是系統因為這些空值的情況，會丟擲空指標異常，導致業務系統發生問題。
此篇文章，總結了幾種關於空值的處理手法，希望對讀者有幫助。
業務中的空值
場景
存在一個
UserSearchService
用來提供使用者查詢的功能：
public
interface
UserSearchService
{
List
<
User
>
listUser
（）；
User
get
（
Integer
id
）；
}
問題現場
對於
面嚮物件語言
來講，抽象層級特別的重要。尤其是對介面的抽象，它在設計和開發中佔很大的比重，我們在開發時希望儘量面向介面程式設計。
對於以上描述的介面方法來看，大概可以推斷出可能它包含了以下兩個含義：
listUser（）
： 查詢使用者列表
get（Integerid）
： 查詢單個使用者
在所有的開發中，XP推崇的TDD模式可以很好的引導我們對介面的定義，所以我們將TDD作為開發程式碼的”推動者”。
對於以上的介面，當我們使用TDD進行測試用例先行時，發現了潛在的問題：
listUser（）
如果沒有資料，那它是返回空集合還是null呢？
get（Integerid）
如果沒有這個物件，是拋異常還是返回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
；
}
對於介面（
ListlistUser（）
），它一定會返回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 UserNotFoundExceptio
*/
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已經提供了很好的整合方案，在此就不在贅述了。
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的的
特例NUllPerso
n），如果修改成這樣，程式碼的可讀性就會變的很強了。
使用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，是返回空集合嗎？還是返回全部的使用者資料集合？”
Optioanl是一種分支的判斷，那我們究竟是關注 Optional還是Optional。get（）呢？
給大家的建議是，如果不想要這樣的歧義，就不要使用它！
如果你真的想表達兩個含義，就給它拆分出兩個介面：
public
interface
UserService
{
List
<
User
>
listUser
（
String
username
）；
List
<
User
>
listUser
（）；
}
我覺得這樣的語義更強，並且更能滿足 軟體設計原則中的 “單一職責”。
如果你覺得你的入參真的有必要可能傳null，那請使用jsr 303或者jsr 305進行說明和驗證！
請記住! Optional不能作為入參的引數!
Optional作為返回值
當個實體的返回
那Optioanl可以做為返回值嗎？
其實它是非常滿足是否存在這個語義的。
你如說，你要根據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
userOpt
=
。。。
如果有這樣的
變數userOp
t，請記住 ：
一定不能直接使用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中！