go語言var 和make

Java中的var是什么

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

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

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

var myMap = mapGenerator();

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

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

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

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

不編譯。 您可以這樣做，因?yàn)槟涿悓?shí)際上在其誕生時(shí)就有一個(gè)名稱，因此當(dāng)實(shí)例分配給聲明為Object類型的變量時(shí)，它們只會(huì)丟失名稱。

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

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

var的未來（只是想法）

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

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因?yàn)槁暶鞅旧頉]有賦值給變量的表達(dá)式。 但是，編譯器可以擴(kuò)展。 從現(xiàn)在開始，我所談?wù)摰牟皇荍ava。 這就是我想象的將來的版本。

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

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

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

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

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

（這個(gè)很好的例子是Nicolai Parlog給出的。）

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

最后，我確實(shí)相信var是Java 11中的出色工具，但我也希望將來它的作用會(huì)得到擴(kuò)展。

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

go語言var 和make

總結(jié)

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

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