差異處
這裏顯示兩個版本的差異處。
java:effective_java:methods:return_optionals_judiciously [2021/07/05 00:06] tony |
java:effective_java:methods:return_optionals_judiciously [2023/06/25 09:48] |
||
---|---|---|---|
行 1: | 行 1: | ||
- | {{tag>java effective_java}} | ||
- | ====== Effective Java - Return optionals judiciously ====== | ||
- | ===== Introduction ===== | ||
- | 這個item主要告訴你使用Java 8推出的Optional的注意事項。本篇文章我以Java開發人員Stuart Marks[[https://www.youtube.com/watch?v=fBYhtvY19xA&t=1833s|演講內容]]與[[https://stuartmarks.files.wordpress.com/2016/09/optionalmotherofallbikesheds3.pdf|投影片]]中所提到的Rules去整理Effective Java與網上的內容。 | ||
- | ==== Rule#1: Never, ever, use null for an Optional variable or return value. ==== | ||
- | 使用Optional的目的,是希望提供一個機制讓method回傳結果能夠表達"no result",而不是透過null,因為null造成了很多的bug。以下為原文: | ||
- | <code> | ||
- | Optional is intended to provide a limited mechanism for library method return types where there is a clear need to represent "no result," and where using null for that is overwhelmingly likely to cause errors. | ||
- | - From Stuart Marks' presentation | ||
- | </code> | ||
- | 因此,當你code讓Optional變數塞了null,或者是直接回傳null,就是脫褲子放屁。老實說,在我們的production code中,還真的有這種code。\\ | ||
- | \\ | ||
- | Effective Java提到適合使用Optional當method回傳值的使用時機: 是你的client需要針對空值做特別處理的時候。 | ||
- | \\ | ||
- | ==== Rule#2: Never use Optional.get() unless you can prove that the Optional is present. ==== | ||
- | 第二個rule是要告訴你別直接使用Optional.get()去取得值,除非你確定它一定有值,如果使用sonarlint,會提示你至少要寫成這樣: | ||
- | <code java> | ||
- | Optional<User> searchResult = userRepository.findUser("123"); | ||
- | if( searchResult.isPresent() ) | ||
- | dump(searchResult.get()); | ||
- | </code> | ||
- | 如果沒先判斷就直接取值,你就會收到java.util.NoSuchElementException: No value present。我們最近也因為有人違反這個rule而產生bug。 | ||
- | \\ | ||
- | ==== Rule#3: Prefer alternatives APIs over Optional.isPresent() and Optional.get(). ==== | ||
- | 延續Rule#2,Optional提供了不少alternative API讓你可以不需要先透過isPresent()判斷,再做後續動作,目的是要讓code更簡潔。以Rule#2中的例子來說,可以寫成這樣: | ||
- | <code java> | ||
- | Optional<User> searchResult = userRepository.findUser("123"); | ||
- | searchResult.ifPresent(TestOptional::dump); | ||
- | </code> | ||
- | 透過ifPresent再傳入Consumer method,就可以讓code更簡潔;除此之外,orElse、orElseGet、orElseThrow也是蠻常使用的。這個[[https://dzone.com/articles/using-optional-correctly-is-not-optional|連結]],敘述了蠻多alternative APIs的使用方法,可以仔細閱讀。 | ||
- | \\ | ||
- | ==== Rule#4: It’s generally a bad idea to create an Optional for the specific purpose of chaining methods from it to get a value. ==== | ||
- | 這個Rule是告訴你,不要為了使用Optional或者是為了fluent interface而使用它,除非你是要回傳Optional: | ||
- | <code java> | ||
- | // BAD | ||
- | String process(String s) { | ||
- | return Optional.ofNullable(s).orElseGet(this::getDefault); | ||
- | } | ||
- | // GOOD | ||
- | String process(String s) { | ||
- | return (s != null) ? s : getDefault(); | ||
- | } | ||
- | </code> | ||
- | 除了考量到效能以外,還要判斷使用Optional以後,code是不是真的比較好閱讀。 | ||
- | \\ | ||
- | ==== Rule#5: If an Optional chain has a nested Optional chain, or has an intermediate result of Optional<Optional<T>>, it’s probably too complex. ==== | ||
- | 這個Rule是說Optional內不要再包Optional,我想這會讓client code變得很複雜。 | ||
- | \\ | ||
- | |||
- | ==== Rule#6: Avoid using Optional in fields, method parameters, and collections. ==== | ||
- | 再來是我研究最久的Rule,探討Optional不該使用在fields、method parameters與collections的情境。\\ | ||
- | \\ | ||
- | 首先談的是collection,在collection的情況下使用Optional,其實是不必要的。主要原因有以下: | ||
- | * 使用Optional後,反而額外增加client要多考慮有值與沒有值的情況。 | ||
- | * collection本身就可以用來代表有值或沒有值的情況,可以參考Effective Java Item#54: [[java:effective_java:methods:return_empty_collections_or_arrays_not_nulls|link]]。 | ||
- | 我目前想的到有可能會把collection用Optional包裝的情況,應該只有用來代表使用者是否有輸入值的情境吧? 當我需要去識別「使用者有否輸入」,就無法使用empty collection去代表這件事情,除非再增加其它的flag變數。\\ | ||
- | \\ | ||
- | 不要將Optional使用於method parameter的原因,主要是會變成強迫client要轉Optional物件,增加API使用的不便性。\\ | ||
- | \\ | ||
- | 最後是最有爭議的,是否要將Optional使用於field。反對者主要有以下論述: | ||
- | * Optional不支援序列化,這個是主因。(列為anti-pattern的主因) | ||
- | * 多消耗4x記憶體空間。(演講中有提及) | ||
- | * Optional是一個box,包覆另外一個value物件,這會增加額外的GC開銷。(演講中有提及) | ||
- | 針對以上三點,序列化問題可以透過Guava Optional或Vivr Optional去解決,但也要搭配[[java:jackson:deepclone|Jackson Module]]或Gson的TypeAdapter做對應的處理;多消耗4x記憶體空間在現在時代已經不是嚴重的事情(Stuart Marks的演講有提及);在Java8的情況下,第三點就無法避免了。\\ | ||
- | 目前已知的是,JDK的[[https://openjdk.java.net/projects/valhalla/|Valhalla]]希望能夠將Optional變成Value Type去避免這個問題,也因為有這個計畫,導致目前無法讓Optional去實作Serializable(會產生向下相容問題)。JodaTime作者認為如果這天來臨,內建的Optional應可以用於任何地方:\\ | ||
- | {{:java:effective_java:methods:effectivejava_item55_optional_with_serializable.png|}}\\ | ||
- | JodaTime作者認為比較好的寫法: | ||
- | <code java> | ||
- | private String mail; // optional | ||
- | public Optional<String> getMail(){ | ||
- | return Optional.ofNullable(mail); | ||
- | } | ||
- | public void setMail(String mail){ | ||
- | this.mail = mail; | ||
- | } | ||
- | </code> | ||
- | \\ | ||
- | 支持者的論點,主要有兩點: | ||
- | * 宣告於欄位代表著非必要欄位,語意表達比使用null加註解清楚,更何況大家都不愛寫註解。[[https://nipafx.dev/stephen-colebourne-java-optional-strict-approach/|link]] | ||
- | * Effective Java Item 55有提及,適用於物件有許多非必要欄位的情況。如果按照Stuart Marks的建議,使用Null Object Pattern,那將會因此建立許多Sub Object,非常不方便。 | ||
- | * 在使用Lombok的情況下,有人會想將Optional宣告為field;但被Lombok開發人員打槍,因為他愛null。[[https://stackoverflow.com/questions/31670785/optional-in-lombok|link]] | ||
- | 支持者與反對者比較寫法如下,我認為trade-off就在對於效能、寫法、序列化與框架的使用上了: | ||
- | <code java> | ||
- | private String mail; // optional | ||
- | private Optional<String> address = Optional.empty(); | ||
- | | ||
- | public Optional<String> getMail(){ | ||
- | return Optional.ofNullable(mail); | ||
- | } | ||
- | | ||
- | public void setMail(String mail){ | ||
- | Objects.requireNonNull(mail, "Mail should not be null."); | ||
- | this.mail = mail; | ||
- | } | ||
- | | ||
- | public Optional<String> getAddress(){ | ||
- | return address; | ||
- | } | ||
- | | ||
- | public void setAddress(String address) { | ||
- | this.address = Optional.of(address); | ||
- | } | ||
- | </code> | ||
- | ==== Rule#7: Avoid using identity-sensitive operations on Optionals. For example don’t use reference equality == with Optionals. ==== | ||
- | 這個Rule是告訴大家不要把Optional的物件使用==去操作,要用equals;除了這個以外,也不要把它拿來synchronized。主要原因是Optional本質上是一個包裝物件的box,未來有很大的機會變成Value Type,參考此[[https://openjdk.java.net/projects/valhalla/|link]]。 | ||
- | ===== 其它 ===== | ||
- | ==== 反對Optional ==== | ||
- | 在演講中有提到有些反對Optional的[[https://homes.cs.washington.edu/~mernst/advice/nothing-is-better-than-optional.html|論述]],有興趣的人可以自行參考。 | ||
- | ==== Effective Java還有提及的 ==== | ||
- | 為了減少boxing與unboxing的開銷,int、long、double可以使用OptionalInt、OptionalLong、OptionalDouble。 | ||
- | ===== Note ===== | ||
- | Effective Java第三版Item 55。 | ||
- | ===== Reference ===== | ||
- | * Effective Java, 3/e | ||
- | * [[https://dzone.com/articles/using-optional-correctly-is-not-optional|26 Reasons Why Using Optional Correctly Is Not Optional]] | ||
- | * [[https://blog.joda.org/2014/11/optional-in-java-se-8.html|Optional in Java SE 8]] | ||
- | * [[https://dzone.com/articles/optional-anti-patterns|Optional Anti-Patterns]] | ||
- | * [[https://youtu.be/fBYhtvY19xA?t=1833|Optional by Stuart Marks]] | ||
- | ===== ===== | ||
- | ---- | ||
- | \\ | ||
- | ~~DISQUS~~ | ||