對于面向對象語言來講，抽象層級特別的重要。尤其是對接口的抽象，它在設計和開發中占很大的比重，我們在開發時希望盡量面向接口編程。對于以上描述的接口方法來看，大概可以推斷出可能它包含了以下兩個含義:
1. listUser(): 查詢用戶列表
2. get(Integer id): 查詢單個用戶
在所有的開發中，XP推崇的TDD模式可以很好的引導我們對接口的定義，所以我們將TDD作為開發代碼的”推動者”。對于以上的接口，當我們使用TDD進行測試用例先行時，發現了潛在的問題：
1. listUser() 如果沒有數據，那它是返回空集合還是null呢？
2. get(Integer id) 如果沒有這個對象，是拋異常還是返回null呢？
### 深入listUser研究
1. 來看一下listUser() 這個列表
```
public?List?listUser(){
???? List?userList?=?userListRepostity.selectByExample(new?UserExample());
if(CollectionUtils.isEmpty(userList)){
//spring?util工具類
returnnull;
???? }
return?userList;
}
```
> 這段代碼返回是null,從開發經驗來講，對于集合這樣返回值，最好不要返回null，因為如果返回了null，會給調用者帶來很多麻煩。你將會把這種調用風險交給調用者來控制。如果調用者是一個謹慎的人，他會進行是否為null的條件判斷。如果他并非謹慎，或者他是一個面向接口編程的狂熱分子(當然，面向接口編程是正確的方向)，他會按照自己的理解去調用接口，而不進行是否為null的條件判斷，如果這樣的話，是非常危險的，它很有可能出現空指針異常！根據墨菲定律來判斷: “很有可能出現的問題，在將來一定會出現!”
### 基于此，我們將它進行優化:
```
public?List?listUser(){
???? List?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){
//從數據庫中通過id直接獲取實體對象
return?userRepository.selectByPrimaryKey(id);
}
```
相信很多人也都會這樣寫。通過代碼的時候得知它的返回值很有可能是null! 但我們通過的接口是分辨不出來的! 這個是個非常危險的事情。尤其對于調用者來說！
我給出的建議是，需要在接口明明時補充文檔,比如對于異常的說明,使用注解@exception:
```
publicinterface?UserSearchService{
/**
???*?根據用戶id獲取用戶信息
???*?@param?id?用戶id
???*?@return?用戶實體
???*?@exception?UserNotFoundException
???*/
User?get(Integer?id);
}
```
我們把接口定義加上了說明之后，調用者會看到，如果調用此接口，很有可能拋出“UserNotFoundException(找不到用戶)”這樣的異常。
這種方式可以在調用者調用接口的時候看到接口的定義，但是，這種方式是”弱提示”的！如果調用者忽略了注釋，有可能就對業務系統產生了風險，這個風險有可能導致一個億！
除了以上這種”弱提示”的方式，還有一種方式是，返回值是有可能為空的。那要怎么辦呢？我認為我們需要增加一個接口，用來描述這種場景. 引入jdk8的Optional,或者使用guava的Optional.看如下定義:
```
publicinterface?UserSearchService{
/**
?*?根據用戶id獲取用戶信息
?*?@param?id?用戶id
?*?@return?用戶實體,此實體有可能是缺省值
?*/
Optional?getOptional(Integer?id);
}
```
Optional有兩個含義: 存在 or 缺省。
那么通過閱讀接口getOptional()，我們可以很快的了解返回值的意圖，這個其實是我們想看到的，它去除了二義性。
它的實現可以寫成:
```
public?Optional?getOptional(Integer?id){
return?Optional.ofNullable(userRepository.selectByPrimaryKey(id));
}
```
### 深入入參
通過上述的所有接口的描述，你能確定入參id一定是必傳的嗎？我覺得答案應該是：不能確定。除非接口的文檔注釋上加以說明。
那如何約束入參呢?
我給大家推薦兩種方式：
1. 強制約束
2. 文檔性約束（弱提示）
1.強制約束，我們可以通過jsr 303進行嚴格的約束聲明:
```
publicinterface?UserSearchService{
/**
??*?根據用戶id獲取用戶信息
??*?@param?id?用戶id
??*?@return?用戶實體
??*?@exception?UserNotFoundException
??*/
User?get(@NotNull?Integer?id);
/**
??*?根據用戶id獲取用戶信息
??*?@param?id?用戶id
??*?@return?用戶實體,此實體有可能是缺省值
??*/
Optional?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 用戶實體
* @throws UserNotFoundException
*/
@CheckForNull
User get(@NonNull Integer id);
/**
* 根據用戶id獲取用戶信息
*
* @param id 用戶id
* @return 用戶實體, 此實體有可能是缺省值
*/
Optional<User> getOptional(@NonNull Integer id);
}
```