Java 8 型別轉換及改進

ImportNew發表於2015-08-13

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

Java 8型別轉換(及改進?)

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的。

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

相關文章