前言
Java 8 引入的 Optional 類型,基本是把它當(dāng)作 null 值優(yōu)雅的處理方式。其實(shí)也不完全如此,Optional 在語義上更能體現(xiàn)有還是沒有值。所以它不是設(shè)計(jì)來作為 null 的替代品,如果方法返回 null 值表達(dá)了二義性,沒有結(jié)果或是執(zhí)行中出現(xiàn)異常。
在 Oracle 做 Java 語言工作的 Brian Goetz 在 Stack Overflow 回復(fù) Should Java 8 getters return optional type? 中講述了引入 Optional 的主要?jiǎng)訖C(jī)。
Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent “no result”, and using null for such was overwhelmingly likely to cause errors.
說的是 Optional 提供了一個(gè)有限的機(jī)制讓類庫方法返回值清晰的表達(dá)有與沒有值,避免很多時(shí)候 null 造成的錯(cuò)誤。并非有了 Optional 就要完全杜絕 NullPointerException。
在 Java 8 之前一個(gè)實(shí)踐是方法返回集合或數(shù)組時(shí),應(yīng)返回空集合或數(shù)組表示沒有元素; 而對(duì)于返回對(duì)象,只能用 null 來表示不存在,現(xiàn)在可以用 Optional 來表示這個(gè)意義。
自 Java8 于 2014-03-18 發(fā)布后已 5 年有余,這里就列舉幾個(gè)我們?cè)陧?xiàng)目實(shí)踐中使用 Optional 常見的幾個(gè)用法。
Optional 類型作為字段或方法參數(shù)
這兒把 Optional 類型用為字段(類或?qū)嵗兞?和方法參數(shù)放在一起來講,是因?yàn)榧偃缥覀兪褂?IntelliJ IDEA 來寫 Java 8 代碼,IDEA 對(duì)于 Optional 作為字段和方法參數(shù)會(huì)給出同樣的代碼建議:
Reports any uses of java.util.Optional<T> , java.util.OptionalDouble , java.util.OptionalInt , java.util.OptionalLong or com.google.common.base.Optional as the type for a field or parameter. Optional was designed to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result". Using a field with type java.util.Optional is also problematic if the class needs to be Serializable , which java.util.Optional is not.
不建議用任何的 Optional 類型作為字段或參數(shù),Optional 設(shè)計(jì)為有限的機(jī)制讓類庫方法返回值清晰的表達(dá) "沒有值"。 Optional 是不可被序列化的,如果類是可序列化的就會(huì)出問題。
上面其實(shí)重復(fù)了 Java 8 引入 Optional 的意圖,我們還有必要繼續(xù)深入理解一下為什么不該用 Optional 作為字段或方法參數(shù)。
當(dāng)我們選擇 Optional 類型而非內(nèi)部包裝的類型后,應(yīng)該是假定了該 Optional 類型不為 null,否則我們?cè)谑褂?Optional 字段或方法參數(shù)時(shí)就變得復(fù)雜了,需要進(jìn)行兩番檢查。
public class User { private String firstName; private Optional<String> middleName = Optional.empty(); private String lastName; public void setMiddleName(Optional<String> middleName) { this.middleName = middleName; } public String getFullName() { String fullName = firstName; if(middleName != null) { if(middleName.isPresent()){ fullName = fullName.concat("." + middleName.get()); } return fullName.concat("." + lastName); }}
由于 middleName 的 setter 方法,我們可能造成 middleName 變?yōu)?null 值,所以在構(gòu)建 fullName 時(shí)必須兩重檢查。
并且在調(diào)用 setMiddleName(...)
方法時(shí)也有些累贅了
user.setMiddleName(Optional.empty());user.setMiddleName(Optional.of("abc"));
而如果字段類型非 Optional 類型,而傳入的方法參數(shù)為 Optional 類型,要進(jìn)行賦值的話
private String middleName; public void updateMiddleName(Optional<String> middleName) { if(middleName != null) { this.middleName = middleName.orElse(null); } else { this.middleName = null; } }
前面兩段代碼如果應(yīng)用 Optional.ofNullable(...)
包裹 Optional 來替代 if(middleName != null)
就更復(fù)雜了。
對(duì)于本例直接用 String 類型的 middleName 作為字段或方法參數(shù)就行,null 值可以表達(dá)沒有 middleName。如果不允許 null 值 middleName, 顯式的進(jìn)行入口參數(shù)檢查而拒絕該輸入 -- 拋出異常。
利用 Optional 過度檢查方法參數(shù)
這一 Optional 的用法與之前的可能為 null 值的方法參數(shù),不分清紅皂白就用 if...else 檢查,總有一種不安全感,步步驚心,結(jié)果可能事與愿違。
public User getUserById(String userId) { if(userId != null) { return userDao.findById(userId); } else { return null; }}
只是到了 Java 8 改成了用 Optional
return if(Optional.ofNullable(userId) .map(id -> userDao.findById(id)) .orElse(null);
上面兩段代碼其實(shí)是同樣的問題,如果輸入的 userId 是 null 值不調(diào)用 findById(...)
方法而直接返回 null 值,這就有兩個(gè)問題
userDao.findById(...)getUserById(userId)
這種情況下立即拋出 NullPointerException 是一個(gè)更好的主意,參考下面的代碼
public User getUserById(String userId) { //拋出出 NullPointerException 如果 null userId return userDao.findById(Objects.requireNoNull(userId, "Invalid null userId");} //orpublic User getUserById(String userId) { //拋出 IllegalArgumentException 如果 null userId Preconditions.checkArgument(userId != null, "Invalid null userId"); return userDao.findById(userId);}
即使用了 Optional 的 orElseThrow 拋出異常也不能明確異常造成的原因,比如下面的代碼
public User getUserById(String userId) { return Optional.ofNullable(userId) .map(id -> userDao.findById(id)) orElseThrow(() -> new RuntimeException("userId 是 null 或 findById(id) 返回了 null 值"));}
糾正辦法是認(rèn)真的審視方法的輸入?yún)?shù),對(duì)不符合要求的輸入應(yīng)立即拒絕,防止對(duì)下層的壓力與污染,并報(bào)告出準(zhǔn)確的錯(cuò)誤信息,以有利于快速定位修復(fù)。
Optional.map(...) 中再次 null 值判斷
假如有這樣的對(duì)象導(dǎo)航關(guān)系 user.getOrder().getProduct().getId()
, 輸入是一個(gè) user 對(duì)象
String productId = Optional.ofNullable(user) .map(User::getOrder) .flatMap(order -> Optional.ofNullable(order.getProduct())) //1 .flatMap(product -> Optional.ofNullable(product.getId())) //2 .orElse("");
#1 和 #2 中應(yīng)用 flatMap 再次用 Optional.ofNullable()
是因?yàn)閾?dān)心 order.getProduct()
或 product.getId()
返回了 null 值,所以又用 Optional.ofNullable(...)
包裹了一次。代碼的執(zhí)行結(jié)果仍然是對(duì)的,代碼真要這么寫的話真是 Oracle 的責(zé)任。這忽略了 Optional.map(...)
的功能,只要看下它的源代碼就知道
public<U> Optional<U> map(Function<? super T, ? extends U> mapper) { Objects.requireNonNull(mapper); if (!isPresent()) return empty(); else { return Optional.ofNullable(mapper.apply(value)); } }
map(...)
函數(shù)中已有考慮拆解后的 null 值,因此呢 flatMap 中又 Optional.ofNullable
是多余的,只需簡單一路用 map(...)
函數(shù)
String productId = Optional.ofNullable(user) .map(User::getOrder) .map(order -> order.getProduct()) //1 .map(product -> product.getId()) //2 .orElse("");
Optional.ofNullable 應(yīng)用于明確的非 null 值
如果有時(shí)候只需要對(duì)一個(gè)明確不為 null 的值進(jìn)行 Optional 包裝的話,就沒有必要用 ofNullable(...)
方法,例如
public Optional<User> getUserById(String userId) { if("ADMIN".equals(userId)) { User adminUser = new User("admin"); return Optional.ofNullable(adminUser); //1 } else { return userDao.findById(userId); }}
在代碼 #1 處非常明確 adminUser 是不可能為 null 值的,所以應(yīng)該直接用 Optional.of(adminUser)
。這也是為什么 Optional 要聲明 of(..)
和 ofNullable(..)
兩個(gè)方法。看看它們的源代碼:
public static <T> Optional<T> of(T value) { return new Optional<>(value); } public static <T> Optional<T> ofNullable(T value) { return value == null ? empty() : of(value); }
知道被包裹的值不可能為 null 時(shí)調(diào)用 ofNullable(value)
多了一次多余的 null 值檢查。相應(yīng)的對(duì)于非 null 值的字面常量
Optional.ofNullable(100); //這樣不好Optional.of(100); //應(yīng)該這么用
小結(jié):
鏈接:
Java 8 Optional use cases
總結(jié)
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,如果有疑問大家可以留言交流,謝謝大家對(duì)VeVb武林網(wǎng)的支持。
新聞熱點(diǎn)
疑難解答
圖片精選