通過(guò)上述的所有接口的描述，你能確定入?yún)d一定是必傳的嗎？我覺(jué)得答案應(yīng)該是：不能確定。除非接口的文檔注釋上加以說(shuō)明。

那如何約束入?yún)⒛?

推薦兩種方式：

•  強(qiáng)制約束
•  文檔性約束（弱提示）

1.強(qiáng)制約束，我們可以通過(guò)jsr 303進(jìn)行嚴(yán)格的約束聲明：   

public interface UserSearchService{  
     /**  
      * 根據(jù)用戶id獲取用戶信息  
      * @param id 用戶id  
      * @return 用戶實(shí)體  
      * @exception UserNotFoundException  
      */  
     User get(@NotNull Integer id);  
     /**  
      * 根據(jù)用戶id獲取用戶信息  
      * @param id 用戶id  
      * @return 用戶實(shí)體,此實(shí)體有可能是缺省值  
      */  
     Optional<User> getOptional(@NotNull Integer id);  
   } 

當(dāng)然，這樣寫(xiě)，要配合AOP的操作進(jìn)行驗(yàn)證，但讓spring已經(jīng)提供了很好的集成方案，在此就不在贅述了。

2.文檔性約束

在很多時(shí)候，我們會(huì)遇到遺留代碼，對(duì)于遺留代碼，整體性改造的可能性很小。

我們更希望通過(guò)閱讀接口的實(shí)現(xiàn)，來(lái)進(jìn)行接口的說(shuō)明。

jsr 305規(guī)范，給了我們一個(gè)描述接口入?yún)⒌囊粋€(gè)方式(需要引入庫(kù) com.google.code.findbugs:jsr305):

可以使用注解: @Nullable @Nonnull @CheckForNull 進(jìn)行接口說(shuō)明。比如: 

public interface UserSearchService{  
   /**  
    * 根據(jù)用戶id獲取用戶信息  
    * @param id 用戶id  
    * @return 用戶實(shí)體  
    * @exception UserNotFoundException  
    */  
   @CheckForNull  
   User get(@NonNull Integer id);  
   /**  
    * 根據(jù)用戶id獲取用戶信息  
    * @param id 用戶id  
    * @return 用戶實(shí)體,此實(shí)體有可能是缺省值  
    */  
   Optional<User> getOptional(@NonNull Integer id);  
 } 

小結(jié)

通過(guò) 空集合返回值,Optional,jsr 303，jsr 305這幾種方式，可以讓我們的代碼可讀性更強(qiáng)，出錯(cuò)率更低！

•  空集合返回值 ：如果有集合這樣返回值時(shí)，除非真的有說(shuō)服自己的理由，否則，一定要返回空集合，而不是null
•  Optional: 如果你的代碼是jdk8，就引入它！如果不是，則使用Guava的Optional,或者升級(jí)jdk版本！它很大程度的能增加了接口的可讀性！
•  jsr 303: 如果新的項(xiàng)目正在開(kāi)發(fā)，不防加上這個(gè)試試！一定有一種特別爽的感覺(jué)!
•  jsr 305: 如果老的項(xiàng)目在你的手上，你可以嘗試的加上這種文檔型注解，有助于你后期的重構(gòu)，或者新功能增加了，對(duì)于老接口的理解!

空對(duì)象模式

場(chǎng)景

來(lái)看一個(gè)DTO轉(zhuǎn)化的場(chǎng)景，對(duì)象:   

@Data  
   static class PersonDTO{  
     private String dtoName;  
     private String dtoAge;  
   }  
   @Data  
   static class Person{ 
     private String name;  
     private String age; 
   } 

需求是將Person對(duì)象轉(zhuǎn)化成PersonDTO，然后進(jìn)行返回。

當(dāng)然對(duì)于實(shí)際操作來(lái)講，返回如果Person為空，將返回null,但是PersonDTO是不能返回null的（尤其Rest接口返回的這種DTO）。

在這里，我們只關(guān)注轉(zhuǎn)化操作，看如下代碼: 

@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ù)轉(zhuǎn)化，可讀性非常差，每個(gè)字段的判斷，如果是空就設(shè)置為空字符串(“”)

換一種思維方式進(jìn)行思考，我們是拿到Person這個(gè)類的數(shù)據(jù)，然后進(jìn)行賦值操作(setXXX),其實(shí)是不關(guān)系Person的具體實(shí)現(xiàn)是誰(shuí)的。

那我們可以創(chuàng)建一個(gè)Person子類: 

static class NullPerson extends Person{  
    @Override  
    public String getAge() {  
      return "";  
    }  
    @Override  
    public String getName() {  
      return "";  
    }  
  } 

它作為Person的一種特例而存在，如果當(dāng)Person為空的時(shí)候，則返回一些 get*的默認(rèn)行為.

所以代碼可以修改為:   

@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 ,則返回空對(duì)象 
    } 

其中 getPerson()方法，可以用來(lái)根據(jù)業(yè)務(wù)邏輯獲取Person有可能的對(duì)象（對(duì)當(dāng)前例子來(lái)講，如果Person不存在，返回Person的的特例NUllPerson），如果修改成這樣，代碼的可讀性就會(huì)變的很強(qiáng)了。

使用Optional可以進(jìn)行優(yōu)化

空對(duì)象模式，它的弊端在于需要?jiǎng)?chuàng)建一個(gè)特例對(duì)象，但是如果特例的情況比較多，我們是不是需要?jiǎng)?chuàng)建多個(gè)特例對(duì)象呢，雖然我們也使用了面向?qū)ο蟮亩鄳B(tài)特性，但是，業(yè)務(wù)的復(fù)雜性如果真的讓我們創(chuàng)建多個(gè)特例對(duì)象，我們還是要再三考慮一下這種模式，它可能會(huì)帶來(lái)代碼的復(fù)雜性。

對(duì)于上述代碼，還可以使用Optional進(jìn)行優(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對(duì)空值的使用，我覺(jué)得更為貼切，它只適用于”是否存在”的場(chǎng)景。

如果只對(duì)控制的存在判斷，我建議使用Optional。

Optioanl的正確使用

Optional如此強(qiáng)大，它表達(dá)了計(jì)算機(jī)最原始的特性(0 or 1),那它如何正確的被使用呢!

Optional不要作為參數(shù)

如果你寫(xiě)了一個(gè)public方法，這個(gè)方法規(guī)定了一些輸入?yún)?shù)，這些參數(shù)中有一些是可以傳入null的，那這時(shí)候是否可以使用Optional呢？

給的建議是: 一定不要這樣使用!

舉個(gè)例子:   

public interface UserService{  
      List<User> listUser(Optional<String> username);  
    } 

這個(gè)例子的方法 listUser,可能在告訴我們需要根據(jù)username查詢所有數(shù)據(jù)集合，如果username是空，也要返回所有的用戶集合.

當(dāng)我們看到這個(gè)方法的時(shí)候，會(huì)覺(jué)得有一些歧義:

 “如果username是absent,是返回空集合嗎？還是返回全部的用戶數(shù)據(jù)集合？”

Optioanl是一種分支的判斷，那我們究竟是關(guān)注 Optional還是Optional.get()呢？

給大家的建議是，如果不想要這樣的歧義，就不要使用它！

如果你真的想表達(dá)兩個(gè)含義，就給它拆分出兩個(gè)接口: 

public interface UserService{  
    List<User> listUser(String username);  
    List<User> listUser();  
  } 

我覺(jué)得這樣的語(yǔ)義更強(qiáng)，并且更能滿足 軟件設(shè)計(jì)原則中的 “單一職責(zé)”。

如果你覺(jué)得你的入?yún)⒄娴挠斜匾赡軅鱪ull,那請(qǐng)使用jsr 303或者jsr 305進(jìn)行說(shuō)明和驗(yàn)證!

請(qǐng)記住! Optional不能作為入?yún)⒌膮?shù)!

Optional作為返回值

當(dāng)個(gè)實(shí)體的返回

那Optioanl可以做為返回值嗎？

其實(shí)它是非常滿足是否存在這個(gè)語(yǔ)義的。

你如說(shuō)，你要根據(jù)id獲取用戶信息，這個(gè)用戶有可能存在或者不存在。

你可以這樣使用: 

public interface UserService{  
   Optional<User> get(Integer id);  
 } 

當(dāng)調(diào)用這個(gè)方法的時(shí)候，調(diào)用者很清楚get方法返回的數(shù)據(jù)，有可能不存在，這樣可以做一些更合理的判斷，更好的防止空指針的錯(cuò)誤！

當(dāng)然，如果業(yè)務(wù)方真的需要根據(jù)id必須查詢出User的話，就不要這樣使用了，請(qǐng)說(shuō)明，你要拋出的異常.

只有當(dāng)考慮它返回null是合理的情況下，才進(jìn)行Optional的返回

集合實(shí)體的返回

不是所有的返回值都可以這樣用的！如果你返回的是集合： 

public interface UserService{  
  Optional<List<User>> listUser();  
} 

這樣的返回結(jié)果，會(huì)讓調(diào)用者不知所措，是否我判斷Optional之后，還用進(jìn)行isEmpty的判斷呢？

這樣帶來(lái)的返回值歧義！我認(rèn)為是沒(méi)有必要的。

我們要約定，對(duì)于List這種集合返回值，如果集合真的是null的，請(qǐng)返回空集合(Lists.newArrayList);

使用Optional變量   

Optional<User> userOpt = ... 

如果有這樣的變量userOpt,請(qǐng)記住 ：

•  一定不能直接使用get ，如果這樣用，就喪失了Optional本身的含義 （ 比如userOp.get() ）
•  不要直接使用getOrThrow ,如果你有這樣的需求：獲取不到就拋異常。那就要考慮，是否是調(diào)用的接口設(shè)計(jì)的是否合理

getter中的使用

對(duì)于一個(gè)java bean,所有的屬性都有可能返回null,那是否需要改寫(xiě)所有的getter成為Optional類型呢？

給大家的建議是，不要這樣濫用Optional.

即便 我java bean中的getter是符合Optional的，但是因?yàn)閖ava bean 太多了，這樣會(huì)導(dǎo)致你的代碼有50%以上進(jìn)行Optinal的判斷，這樣便污染了代碼。(我想說(shuō)，其實(shí)你的實(shí)體中的字段應(yīng)該都是由業(yè)務(wù)含義的，會(huì)認(rèn)真的思考過(guò)它存在的價(jià)值的，不能因?yàn)镺ptional的存在而濫用)

我們應(yīng)該更關(guān)注于業(yè)務(wù)，而不只是空值的判斷。

不要在getter中濫用Optional.

小結(jié)

可以這樣總結(jié)Optional的使用：

•  當(dāng)使用值為空的情況，并非源于錯(cuò)誤時(shí)，可以使用Optional!
•  Optional不要用于集合操作!
•  不要濫用Optional,比如在java bean的getter中!