※ 引述《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自己做决定 :)