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();
}

我們可以使用 flatMap 一步完成過濾和強制轉換：

FlatMap的實現：

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

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

成本和收益

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

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

對於一箇中等水平的開發者來說，它們是否能提高程式碼的可讀性？

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

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

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

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