Java 8類型轉換（及改進？）

為對象的類型做強制轉換是一種非常不好的設計。但在某些情況下，我們沒有其他選擇。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 轉型的測試結果，與靜態轉型的結果是完全一致的。

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();
}</pre> 
我們可以使用 flatMap 一步完成過濾和強制轉換： 

FlatMap的實現： 

Stream<?> stream; // may contain integers
Stream<Integer> streamOfInts = stream.
        flatMap(Integer.class::castIntoStream);
 
錯誤的實例類型或者null引用，在實例測試的時候會失敗，所以返回空的 Optional 或 Stream。這種方式永遠不會拋出 ClassCastException 異常。 

成本和收益 

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

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

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

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

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

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

你怎么認為的呢？你自己會使用這些方法嗎？ 
原文鏈接： javacodegeeks 翻譯： ImportNew.com - paddx 

譯文鏈接： http://www.importnew.com/16502.html