Effective Java - Return optionals judiciously

這個item主要告訴你使用Java 8推出的Optional的注意事項。本篇文章我以Java開發人員Stuart Marks演講內容投影片中所提到的Rules去整理Effective Java與網路上的內容。

Rule#1: Never, ever, use null for an Optional variable or return value.

使用Optional的目的,是希望提供一個機制讓method回傳結果能夠表達“no result”,而不是透過null,因為null造成了很多的bug。以下為原文:

Optional is intended to provide a limited mechanism for library method return types where there is a clear need to represent "no result," and where using null for that is overwhelmingly likely to cause errors. 
                                                                       - From Stuart Marks' presentation
除此之外,也可以參考Java Language Architect - Brian Goetz的說法。 因此,當你讓Optional變數塞了null,或者是直接回傳null,就是脫褲子放屁;而在我們的production code中,還真的有這種code。

另外,Effective Java有提到適合使用Optional當method回傳值的使用時機: 是你的client需要針對空值做特別處理的時候。

Rule#2: Never use Optional.get() unless you can prove that the Optional is present.

第二個rule是要告訴你別直接使用Optional.get()去取得值,除非你確定它一定有值,如果使用sonarlint,會提示你至少要寫成這樣:

Optional<User> searchResult = userRepository.findUser("123");
    if( searchResult.isPresent() )
        dump(searchResult.get());
如果沒先判斷就直接取值,你就會收到java.util.NoSuchElementException: No value present。我們最近也因為有人違反這個rule而產生bug。

Rule#3: Prefer alternatives APIs over Optional.isPresent() and Optional.get().

延續Rule#2,Optional提供了不少alternative API讓你可以不需要先透過isPresent()判斷,再做後續動作,目的是要讓code更簡潔。以Rule#2中的例子來說,可以寫成這樣:

Optional<User> searchResult = userRepository.findUser("123");
searchResult.ifPresent(TestOptional::dump);
透過ifPresent再傳入Consumer method,就可以讓code更簡潔;除此之外,orElse、orElseGet、orElseThrow也是蠻常使用的。這個連結敘述了蠻多alternative APIs的使用方法,可以仔細閱讀。

Rule#4: It’s generally a bad idea to create an Optional for the specific purpose of chaining methods from it to get a value.

這個Rule是告訴你,不要為了使用Optional或者是為了fluent interface而使用它,除非你是要回傳Optional:

// BAD	
String process(String s) {	
    return Optional.ofNullable(s).orElseGet(this::getDefault);	
}	
// GOOD	
String process(String s) {	
    return (s != null) ? s : getDefault();	
}
除了考量到效能以外,還要判斷使用Optional以後,code是不是真的比較好閱讀。

Rule#5: If an Optional chain has a nested Optional chain, or has an intermediate result of Optional<Optional<T>>, it’s probably too complex.

這個Rule是說Optional內不要再包Optional,我想這會讓client code變得很複雜。

Rule#6: Avoid using Optional in fields, method parameters, and collections.

再來是我研究最久的Rule,建議Optional避免使用在fields、method parameters與collections。

首先談的是collection,在collection的情況下使用Optional,其實是不必要的。主要原因有以下:

  • 使用Optional後,反而額外增加client要多考慮有值與沒有值的情況。
  • collection本身就可以用來代表有值或沒有值的情況,可以參考Effective Java Item#54: link

我目前想的到有可能會把collection用Optional包裝的情況,應該只有用來代表使用者是否有輸入值的情境吧? 當我需要去識別「使用者有否輸入」,就無法使用empty collection去代表這件事情,除非再增加其它的flag變數。

不要將Optional使用於method parameter的原因,主要是會變成強迫client要轉Optional物件,增加API使用的不便性。

最後是最有爭議的,是否要將Optional使用於field。反對者主要有以下論述:

  • Optional不支援序列化,這個是主因。(列為anti-pattern的主因)
  • 多消耗4倍記憶體空間。(演講中有提及)
  • Optional是一個box,包覆另外一個value物件,這會增加額外的GC開銷。(演講中有提及)

針對以上三點,序列化問題可以透過Guava Optional或Vivr Optional去解決,但也要搭配Jackson Module或Gson的TypeAdapter做對應的處理;多消耗4倍記憶體空間在現在時代已經不是嚴重的事情(Stuart Marks的演講有提及);在Java8的情況下,第三點就無法避免了。
目前已知的是,JDK的Valhalla專案希望能夠將Optional變成Value Type去避免這個問題,也因為有這個計畫,導致目前無法讓Optional去實作Serializable(會產生向下相容問題)。JodaTime作者認為如果這天來臨,內建的Optional應可以用於任何地方:

JodaTime作者認為比較好的寫法:

private String mail; // optional
public Optional<String> getMail(){
    return Optional.ofNullable(mail);
} 
public void setMail(String mail){
    this.mail = mail;
}

支持者的論點,主要有兩點:

  • 宣告於欄位代表著非必要欄位,語意表達比使用null加註解清楚,更何況大家都不愛寫註解。此外,這個Optional支持者反對null,不偏好JodaTime作者的方法。link
  • Effective Java Item 55有提及,適用於物件有許多非必要欄位的情況,像是部分更新的UseCaseInput model。如果按照Stuart Marks的建議使用Null Object Pattern,那將會因此建立許多Sub Classes,非常不方便。
  • 在使用Lombok的情況下,有人會想將Optional宣告為field;但被Lombok開發人員打槍,因為他愛null。link

支持者與反對者比較寫法如下,我認為trade-off就在對於效能、語意、序列化與框架的使用上了,單元測試成本幾乎是一樣的:

private String mail; // optional
private Optional<String> address = Optional.empty();
 
public Optional<String> getMail(){
    return Optional.ofNullable(mail);
}
 
public void setMail(String mail){ 
    Objects.requireNonNull(mail, "Mail should not be null.");
    this.mail = mail;
}
 
public Optional<String> getAddress(){
    return address;
}
 
public void setAddress(String address) {
    this.address = Optional.of(address);
}
在Java 8的情況下,我提供以下主要的trade-off比較給大家參考:

  • 允許Optional於欄位讓語意清楚: 效能較差、維護成本較高(有序列化需求要特別套其它library)。
  • 允許null於欄位並僅在回傳值使用Optional: 僅有語意問題,null控制好就無大礙。

Rule#7: Avoid using identity-sensitive operations on Optionals. For example don’t use reference equality == with Optionals.

這個Rule是告訴大家不要把Optional的物件使用==去操作,要用equals;除了這個以外,也不要把它拿來synchronized。主要原因是Optional本質上是一個包裝物件的box,未來有很大的機會變成Value Type,參考此link

反對Optional

在演講中有提到有些反對Optional的論述,有興趣的人可以自行參考。

Effective Java還有提及的

  1. 為了減少boxing與unboxing的開銷,int、long、double可以使用OptionalInt、OptionalLong、OptionalDouble。
  2. 不建議使用在map的key上,因為Optional包含著有值與沒有值的情況,使用在map上只是增添不必要的複雜度。最後再次強調: it is almost never appropriate to use an optional as a key, value, or element in a collection or array.

Effective Java第三版Item 55。