※ 引述《JustinHere (良葛格)》之銘言：
: ※ 引述《popcorny (畢業了..@@")》之銘言：
: : 其實我覺得最簡單的原則應該是，
: : 方法的傳入值，傳回值，field都不應該出現Optional
: 我在 Java TWO 的會上有談到 Optional：
: http://www.codedata.com.tw/java/jdk8-functional-api/
: 其中談到 Optional 的作用之一是文件化，因此，傳回值型態上，如果你想要
: 明確提示 API 客戶端，必須檢查結果可能是空的情況時，可能就是使用 Optional
: 的時機。
: 因此，對於那些本身有定義「空」或「無值」的 API，像是 List，可以不使用
: Optional<List>，而這些 API 在沒有結果時，應該傳回本身定義的「空」，例如
: Collections.emptyList()，字串在這部份是比較尷尬，它有空字串的概念，不過
: 很多情況下，開發者在沒有結果而傳回型態是字串時，習慣傳回 null，這時選擇
: 就多了…
: 1. 統一傳回 null
: 2. 統一傳回 ""
: 3. 統一傳回 Optional<String>
: 對於前兩者，可以在不更動 API 的情況下，修改實作做到，像 guava-libraries，
: 提供了 emptyToNull 或 nullToEmpty 來這件事。
: 再來就是亡羊補牢判定法吧！對那些常常出現 NullPointerException 的地方，改用
: Optional，這樣最簡單…顯然地，這些地方本身不改就會出問題了嘛…XD
其實我也一直思考這個問題，
回傳Optional<T>是有文件化的好處
但我想法是這樣
1. 能否保證所有API的一致性。
當然團隊說好就好，我相信不會是問題。
但是如果有些回傳Optional，
有些沒有回傳Optional卻有可能是null。
會感覺整體使用不夠一致的問題。
2. 對client是否有比較好用?
如果大部份的需求只是
Book book = dao.findBook();
if(book!=null) {
book.getName();
}
這對使用者使用上簡單明瞭，且少了一層轉換
若用Optional當回傳值的話
Optional<Book> optBook = dao.findBook();
if(optBook.isPresent()){
Book book = optBook.get();
//book.xxx
});
或是
Book book = dao.findBook().orElse(null);
if(book != null) {
//book.xxx
}
或
dao.findBook().ifPresent((book)->{
//book.xxx
});
多少會瑣碎一點點。
畢竟Optional<Book>不能直接拿來用
我們要的是Book，
所以要先轉回Book
而且要享用Optional的好處，
即使在方法回傳型態不是Optional也可以使用
Book book = Optional.ofNullable(dao.findBook()).orElse(...);
只是到底要callee強迫使用Optional
還是caller自己決定要不要用Optional而已
3. 幫助文件化。這個當然Optional可以做到這方面的"convention"，
但是這要看Java生態圈的文化發展，
如果已經發展成大家都很習慣這樣使用了
我覺得當然就follow convention。
但也不是沒有其他方法可以標示回傳是否允許Null
例如使用FindBugs的@Nullable
用annotation的方法感覺對程式有比較小的影響
public @Nullable Book findBook() { ...}
我的立場是不反對Optional當回傳值
(但反對POJO回傳Optional)
只是比較推薦不要放Optional為回傳值，
因為算是比較簡單的做法，
至於是否使用Optional，
就全部交給caller自己做決定 :)