為對象的類型做強制轉換是一種很不好的設計。但在某些情況下，我們沒有其它選擇。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的。

你怎麽覺得的呢？你自己會使用這些方法嗎？

Java 8 類型轉換及改進