為對(duì)象的類型做強(qiáng)制轉(zhuǎn)換是一種非常不好的設(shè)計(jì)。但在某些情況下，我們沒有其他選擇。Java自誕生的那一天起，就具備這種功能。

我認(rèn)為Java 8在一定程度改善了這項(xiàng)古老的技術(shù)。

靜態(tài)轉(zhuǎn)型

Java中最常用的轉(zhuǎn)型方式如下：

靜態(tài)轉(zhuǎn)型

Object obj; // may be an integer 
if (obj instanceof Integer) { 
    Integer objAsInt = (Integer) obj; 
    // do something with 'objAsInt' 
} 

這里使用了 instanceof 和轉(zhuǎn)型操作符，這些操作符已經(jīng)融入到語(yǔ)言當(dāng)中了。對(duì)象轉(zhuǎn)換的類型（這個(gè)例子中是Integer）必須是在編譯期靜態(tài)確定的，所以我們將這種轉(zhuǎn)型稱為靜態(tài)轉(zhuǎn)型。

如果obj不是Integer，上面的測(cè)試就會(huì)失敗。如果我們以任何方式做類型轉(zhuǎn)換，就會(huì)得到一個(gè) ClassCastException 異常。如果obj是null，intanceof 測(cè)試會(huì)失敗，但是轉(zhuǎn)型是可以通過(guò)的，因?yàn)閚ull可以被任何類型引用。

動(dòng)態(tài)轉(zhuǎn)型

有一種不常見的技術(shù)，即使用Class的方法，這些方法與上面的操作符的作用是一致的。

動(dòng)態(tài)轉(zhuǎn)換成已知類型

Object obj; // may be an integer 
if (Integer.class.isInstance(obj)) { 
    Integer objAsInt = Integer.class.cast(obj); 
    // do something with 'objAsInt' 

注意，這個(gè)例子中類型的轉(zhuǎn)換也是在編譯期確定的，所以沒有必要這么去做。

動(dòng)態(tài)轉(zhuǎn)型

Object obj; // may be an integer 
Class<T> type = // may be Integer.class 
if (type.isInstance(obj)) { 
    T objAsType = type.cast(obj); 
    // do something with 'objAsType' 
} 

因?yàn)檗D(zhuǎn)換的類型在編譯期是不知道，所以我們將這種轉(zhuǎn)型稱之為動(dòng)態(tài)轉(zhuǎn)型。

對(duì)錯(cuò)誤類型和 null 轉(zhuǎn)型的測(cè)試結(jié)果，與靜態(tài)轉(zhuǎn)型的結(jié)果是完全一致的。

[[145172]]

Stream及Optional的轉(zhuǎn)型

現(xiàn)在

對(duì) Optional 中的值或 Stream 中的元素轉(zhuǎn)型需要兩個(gè)步驟：***步，我們需要過(guò)濾掉錯(cuò)誤的類型，然后我們需要將其轉(zhuǎn)換為目標(biāo)類型。

Optional中的轉(zhuǎn)型

Optional<?> obj; // may contain an Integer 
Optional<Integer> objAsInt = obj 
        .filter(Integer.class::isInstance) 
        .map(Integer.class::cast); 

我們需要兩個(gè)步驟來(lái)完成轉(zhuǎn)型，這雖然不是什么大問(wèn)題，但是我感覺還是有一點(diǎn)笨拙和冗余。

未來(lái)（可能）

我建議Class的強(qiáng)制轉(zhuǎn)型方法能返回一個(gè) Optional 或者 Stream。如果傳遞的對(duì)象的類型是正確的，則返回一個(gè)包含該對(duì)象的Optional或Stream。否則返回的Optional或Stream不包含任何元素。

這些方法的實(shí)現(xiàn)比較瑣碎：

Class上的新方法

public Optional<T> castIntoOptional(Object obj) { 
    if (isInstance(obj)) 
        return Optional.of((T) obj); 
    else 
        Optional.empty(); 
} 
 
public Stream<T> castIntoStream(Object obj) { 
    if (isInstance(obj)) 
        return Stream.of((T) obj); 
    else 
        Stream.empty(); 
} 

我們可以使用 flatMap 一步完成過(guò)濾和強(qiáng)制轉(zhuǎn)換：

FlatMap的實(shí)現(xiàn)：

Stream<?> stream; // may contain integers 
Stream<Integer> streamOfInts = stream. 
flatMap(Integer.class::castIntoStream); 

錯(cuò)誤的實(shí)例類型或者null引用，在實(shí)例測(cè)試的時(shí)候會(huì)失敗，所以返回空的 Optional 或 Stream。這種方式永遠(yuǎn)不會(huì)拋出 ClassCastException 異常。

成本和收益

我們?cè)趺磥?lái)衡量這些方法是否真正有用呢？

有多少代碼真正會(huì)使用它們？

對(duì)于一個(gè)中等水平的開發(fā)者來(lái)說(shuō)，它們是否能提高代碼的可讀性？

是否值得為其節(jié)約一行代碼？

實(shí)現(xiàn)和維護(hù)它們的成本是多少？

我對(duì)這些問(wèn)題的回答是：不多，是非常少。所以，這是一個(gè)總和趨近于0的游戲，但是，我可以證明雖然收益不多，但卻是大于0的。

你怎么認(rèn)為的呢？你自己會(huì)使用這些方法嗎？