W作者popcorny (畢業了..@@")
看板java
標題Re: [心得] Java8的Optional心得建議
時間Fri Aug 8 13:13:27 2014
※ 引述《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自己做決定 :)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.46.230
※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1407474809.A.83E.html
※ 編輯: popcorny (118.163.46.230), 08/08/2014 13:14:28
※ 編輯: popcorny (118.163.46.230), 08/08/2014 13:18:36
※ 編輯: popcorny (118.163.46.230), 08/08/2014 13:19:47
※ 編輯: popcorny (118.163.46.230), 08/08/2014 13:23:25
1F：推 JustinHere:主要是多一個機制，讓大家多思考一點… 08/08 15:44
3F：推 JustinHere:其實還可以多思考別的方法，像是 Null Object Pattern 08/08 16:07
4F：→ JustinHere:用來取代那些一開始沒有定義「無」或「空」的 API 08/08 16:08
5F：→ swpoker:上面還好解決~通常就是回傳物件就會有尷尬的問題 08/08 16:14
6F：推 Killercat:其實就根當年的C++到底要傳pointer還是auto_ptr一樣尷尬 08/08 17:36
7F：→ Killercat:每種語言似乎都難免會碰到這種尷尬的例子 08/08 17:36
8F：→ undeadj: 有點多此一舉 08/10 07:53