為對象的類型做強制轉換是一種非常不好的設計。但在某些情況下，我們沒有其他選擇。Java自誕生的那一天起，就具備這種功能。

我認為Java 8在一定程度改善了這項古老的技術。

靜態轉型

Java中最常用的轉型方式如下：

靜態轉型

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

這里使用了 instanceof 和轉型操作符，這些操作符已經融入到語言當中了。對象轉換的類型（這個例子中是Integer）必須是在編譯期靜態確定的，所以我們將這種轉型稱為靜態轉型。

如果obj不是Integer，上面的測試就會失敗。如果我們以任何方式做類型轉換，就會得到一個 ClassCastException 異常。如果obj是null，intanceof 測試會失敗，但是轉型是可以通過的，因為null可以被任何類型引用。

動態轉型

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

動態轉換成已知類型

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

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

動態轉型

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' 
} 

因為轉換的類型在編譯期是不知道，所以我們將這種轉型稱之為動態轉型。

對錯誤類型和 null 轉型的測試結果，與靜態轉型的結果是完全一致的。

[[145172]]

Stream及Optional的轉型

現在

對 Optional 中的值或 Stream 中的元素轉型需要兩個步驟：***步，我們需要過濾掉錯誤的類型，然后我們需要將其轉換為目標類型。

Optional中的轉型

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

我們需要兩個步驟來完成轉型，這雖然不是什么大問題，但是我感覺還是有一點笨拙和冗余。

未來（可能）

我建議Class的強制轉型方法能返回一個 Optional 或者 Stream。如果傳遞的對象的類型是正確的，則返回一個包含該對象的Optional或Stream。否則返回的Optional或Stream不包含任何元素。

這些方法的實現比較瑣碎：

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 一步完成過濾和強制轉換：

FlatMap的實現：

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

錯誤的實例類型或者null引用，在實例測試的時候會失敗，所以返回空的 Optional 或 Stream。這種方式永遠不會拋出 ClassCastException 異常。

成本和收益

我們怎么來衡量這些方法是否真正有用呢？

有多少代碼真正會使用它們？

對于一個中等水平的開發者來說，它們是否能提高代碼的可讀性？

是否值得為其節約一行代碼？

實現和維護它們的成本是多少？

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

你怎么認為的呢？你自己會使用這些方法嗎？