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。

我目前想的到有可能會把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還有提及的

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

Reference:

Effective Java, 3/e, Item 55。
26 Reasons Why Using Optional Correctly Is Not Optional
Optional in Java SE 8
Optional Anti-Patterns
Optional by Stuart Marks
Should Java 8 getters return optional type?

阿兩的筆記本 Ryoutsu's Notebook

搜尋此網誌