Re: [心得] Java8的Optional心得建議

看板java作者時間9年前 (2014/08/08 13:13), 9年前編輯推噓4(404)
留言8則, 4人參與, 最新討論串3/3 (看更多)
※ 引述《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://www.ptt.cc/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

08/08 15:44, , 1F
主要是多一個機制,讓大家多思考一點…
08/08 15:44, 1F

08/08 15:53, , 2F

08/08 16:07, , 3F
其實還可以多思考別的方法,像是 Null Object Pattern
08/08 16:07, 3F

08/08 16:08, , 4F
用來取代那些一開始沒有定義「無」或「空」的 API
08/08 16:08, 4F

08/08 16:14, , 5F
上面還好解決~通常就是回傳物件就會有尷尬的問題
08/08 16:14, 5F

08/08 17:36, , 6F
其實就根當年的C++到底要傳pointer還是auto_ptr一樣尷尬
08/08 17:36, 6F

08/08 17:36, , 7F
每種語言似乎都難免會碰到這種尷尬的例子
08/08 17:36, 7F

08/10 07:53, , 8F
有點多此一舉
08/10 07:53, 8F
文章代碼(AID): #1Jv5nvW- (java)
文章代碼(AID): #1Jv5nvW- (java)