Java中的var是什么

Java 10中引入的var預(yù)定義類型使您可以在為變量分配值時聲明局部變量，而無需指定變量的類型。 當(dāng)您為變量分配值時，表達(dá)式的類型已經(jīng)定義了變量的類型，因此沒有理由在行的左側(cè)再次鍵入類型。 例如，當(dāng)您有一些帶有許多泛型的復(fù)雜長類型時，這特別好

HashMap<String,TreeMap<Integer,String> myMap = mapGenerator();

您可以在先前的Java版本中繼承的泛型類型，但是現(xiàn)在您只需鍵入

var myMap = mapGenerator();

這比以前的版本更簡單，并且大多數(shù)時候可讀性更高。 var的目的主要是可讀性。 重要的是要了解，以這種方式聲明的變量將具有類型，并且此新的預(yù)定義類型（不是關(guān)鍵字）的引入不會使Java成為動態(tài)語言。 您可以通過某些方式做到這一點，這是您以前無法做到的，或者只能以更冗長的方式做到。 例如，當(dāng)您將匿名類的實例分配給變量時，可以通過var聲明的變量調(diào)用該類中的聲明方法。 例如：

var m = new Object{ void z(){} } mz();

您可以調(diào)用方法z()但代碼

Object m = new Object{ void z(){} } mz();

無法編譯。 您可以這樣做，因為匿名類實際上在其誕生時就有一個名稱，因此當(dāng)實例分配給聲明為Object類型的變量時，它們只會丟失名稱。

var關(guān)鍵字有一些陰暗的部分。 這樣，我們違反了實例化具體類的一般規(guī)則，但是將變量聲明為接口。 這是一個通常在Java中通常遵循的通用抽象規(guī)則。 創(chuàng)建返回HashMap的方法時，通常將返回值聲明為Map 。 這是因為HashMap是返回值的實現(xiàn)，因此與調(diào)用者無關(guān)。 我在返回類型中聲明的是我返回實現(xiàn)Map接口的東西。 我的工作方式是我自己的責(zé)任。 同樣，如果可能的話，我們通常將類中的字段聲明為某種接口類型。 局部變量也應(yīng)遵循相同的規(guī)則。 幾次，當(dāng)我聲明要Set的局部變量但對實際值是TreeSet然后鍵入代碼時，對我很有幫助。 然后我意識到我使用的不是Set而是SortedSet某些功能。 它幫助我意識到sorting-ness在特殊情況下很重要，并且對于調(diào)用者也很重要，因此我不得不將方法的返回類型也更改為SortedSet 。 請注意，此示例中的SortedSet仍然是接口，而不是實現(xiàn)類。

通過使用var我們將失去它，并且獲得了稍微簡單一些的源代碼。 一如既往，這是一個折衷。 在使用局部變量的情況下，就源代碼而言，該變量的使用與聲明很接近，因此開發(fā)人員可以一目了然地看到什么是正在發(fā)生的事情，因此這種折衷的“壞”方面是可以接受的。 在方法返回值或字段的情況下，無法進(jìn)行相同的折衷。 這些類成員的使用可以在不同的類，不同的模塊中。 看到這些值的所有用法不僅很困難，而且也可能是不可能的，因此，這里我們?nèi)匀谎赜门f的方式：聲明類型。

var的未來（只是想法）

在某些情況下，甚至不能將var用于局部變量。 很多時候，我們有以下編碼模式：

final var variable; // this does not work in Java 11 if ( some condition ) { variable = expression_1 // do something here } else { variable = expression_2 // do something here }

在這里我們不能使用var因為在聲明本身上沒有分配變量的表達(dá)式。 但是，編譯器可以擴(kuò)展。 從現(xiàn)在開始，我所談?wù)摰牟皇荍ava，而是現(xiàn)在。 這就是我想象的將來的版本。

如果結(jié)構(gòu)簡單并且“在這里做某事”為空，則可以將結(jié)構(gòu)轉(zhuǎn)換為三元運算符：

final var variable = some condition ? ( expression_1 ) : (expression_2) var variable = some condition ? ( expression_1 ) : (expression_2)

在這種情況下，即使我們使用Java的舊版本，例如Java 11，也可以使用var聲明。但是，請小心！

var h = true ? 1L : ? 1L : 3.3 ;

在此示例中，變量h的實際類型是什么？ Number ？ 三元運算符具有復(fù)雜且特殊的類型強(qiáng)制規(guī)則，由于兩個表達(dá)式彼此靠近，通常不會引起任何問題。 如果我們讓上述結(jié)構(gòu)使用類似的類型強(qiáng)制，則表達(dá)式彼此之間的距離并不那么緊密。 到目前為止，Java的距離足夠遠(yuǎn)，不允許使用var類型定義。 我個人的觀點是，應(yīng)在將來的某個時候擴(kuò)展var聲明，以允許使用上述結(jié)構(gòu)，但僅當(dāng)兩個（或兩個或更復(fù)雜的結(jié)構(gòu)）表達(dá)式具有完全相同的類型時才可以。 否則，我們可能最終得到一個表達(dá)式，該表達(dá)式導(dǎo)致一個int ，另一個表達(dá)式導(dǎo)致一個String ，那么變量的類型將是什么？ 回答前請勿偷看圖片！

（這個很好的例子是Nicolai Parlog給出的。）

我還可以想象，將來我們將擁有類似于Scala val東西，它是Java 11中的final var 。我不喜歡var vs. val命名。 這是極度性感和怪異的，但很容易將一個人誤認(rèn)為另一個人。 但是，如果我們有一個以final關(guān)鍵字開頭的局部變量聲明，那么為什么之后需要var關(guān)鍵字呢？

最后，我確實相信var是Java 11中的一個很棒的工具，但是我也希望它的作用將來會得到擴(kuò)展。

翻譯自: https://www.javacodegeeks.com/2019/03/var-language-design.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的Var和语言设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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