將實例轉(zhuǎn)換為設(shè)計不良的類型。 盡管如此，在某些情況下沒有其他選擇。 從第一天開始，這種能力就已經(jīng)成為Java的一部分。

我認為Java 8提出了對這種古老技術(shù)稍加改進的需求。

靜態(tài)鑄造

用Java進行轉(zhuǎn)換的最常見方法如下：

靜態(tài)鑄造

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

這使用了嵌入到該語言中的instanceof和cast運算符。 實例轉(zhuǎn)換為的類型（在本例中為Integer在編譯時必須是靜態(tài)已知的，因此我們將其稱為靜態(tài)轉(zhuǎn)換。

如果obj不是Integer ，則上述測試將失敗。 如果我們嘗試將其強制轉(zhuǎn)換，則會得到ClassCastException 。 如果obj為null ，則它無法通過instanceof測試，但可以強制轉(zhuǎn)換，因為null可以是任何類型的引用。

動態(tài)鑄造

我很少遇到的一種技術(shù)是使用Class上與運算符相對應(yīng)的方法：

動態(tài)轉(zhuǎn)換為已知類型

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

請注意，盡管在此示例中，在編譯時也知道要強制轉(zhuǎn)換為的類，但不一定如此：

動態(tài)鑄造

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

因為類型在編譯類型時是未知的，所以我們將其稱為動態(tài)轉(zhuǎn)換。

類型和空引用錯誤的實例的測試和轉(zhuǎn)換結(jié)果與靜態(tài)轉(zhuǎn)換完全相同。

由vankarsten在CC-BY-NC 2.0下發(fā)布 。

在流中投放和可選

現(xiàn)在

轉(zhuǎn)換Optional的值或Stream的元素是一個兩步過程：首先，我們必須過濾掉錯誤類型的實例，然后才能將其轉(zhuǎn)換為所需的類型。

使用Class上的方法，我們使用方法引用來實現(xiàn)。 以O(shè)ptional為例：

強制轉(zhuǎn)換

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

我們需要兩個步驟來執(zhí)行此操作沒什么大不了的，但是我覺得這有點尷尬，而且比必要時更冗長。

未來（也許）

我建議在Class上實現(xiàn)返回Optional或Stream轉(zhuǎn)換方法。 如果傳遞的實例類型正確，則將返回Optional或包含轉(zhuǎn)換實例的Singleton Stream 。 否則，兩者都將為空。

實現(xiàn)這些方法很簡單：

課堂上的新方法

public Optional<T> castIntoOptional(Object obj) {if (isInstance(obj))return Optional.of((T) obj);elseOptional.empty(); }public Stream<T> castIntoStream(Object obj) {if (isInstance(obj))return Stream.of((T) obj);elseStream.empty(); }

這使我們可以使用flatMap一步進行過濾和轉(zhuǎn)換：

該死的FlatMap

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

類型錯誤或引用為空的實例將使實例測試失敗，并導(dǎo)致空的Optional或Stream 。 永遠不會有ClassCastException 。

成本與收益

還需要確定這些方法是否會發(fā)揮自己的作用：

• 實際可以使用多少代碼？
• 它們會提高普通開發(fā)人員的可讀性嗎？
• 節(jié)省一行值得嗎？
• 實施和維護它們的成本是多少？

我回答的問題不多 ， 很少 ， 是的 ， 很少 。 因此，它接近于零和游戲，但我確信這是一個很小但不可忽略的收益。

你怎么看？ 您看到自己使用這些方法了嗎？

翻譯自: https://www.javacodegeeks.com/2015/07/casting-in-java-8-and-beyond.html

總結(jié)

以上是生活随笔為你收集整理的在Java 8中进行投射（还有其他功能？）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。