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/cn.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