簡(jiǎn)評(píng):Java var != JavaScript var。
Java 10 中引入了新的語(yǔ)法用于局部變量類型推斷,很多開(kāi)發(fā)者有所疑惑,希望這篇文章能幫到你。
什么是類型推斷
其實(shí)在 Java 中類型推斷早就存在了,看下下面的例子:
public void doSomething() {
final List<String> names = new ArrayList<String>();
// ^^^^^^------- Redundant
...
}
在這個(gè)例子中給 ArrayList 定義持有的類型就沒(méi)必要了,因?yàn)?List<String> 已經(jīng)定義了我們需要的類型 String ,在 Java 7 中增加了類型推斷,這時(shí)例子可以直接寫成
public void doSomething() {
final List<String> names = new ArrayList<>();
// ^^------ Inferred!
...
}
這兩種寫法是完全合法的,而且最終會(huì)形成一樣的字節(jié)碼。對(duì)經(jīng)常使用泛型的開(kāi)發(fā)者來(lái)說(shuō),可能早就對(duì)上面的類型推斷寫法習(xí)以為常。
那什么是局部變量類型推斷?
即能推斷出方法中局部變量的類型,這是 Java 10 中新增的特性,對(duì)應(yīng)關(guān)鍵詞 var,看個(gè)例子 :
public void doSomething() {
final ??? name = "Todd";
}
name 是什么類型,很明顯是 String,而 Java 10 就可以讓編譯器幫我們判斷其類型,我們只要寫成下面的形式:
public void doSomething() {
final var name = "Todd"; // name is inferred as a String!
}
var 的使用不局限于函數(shù)內(nèi)聲明的變量,同時(shí)也可以用于循環(huán)的索引:
final List<String> names = new ArrayList<>();
public void doSomething() {
for(var name: names) {
System.out.println("Name: " + name);
}
for(var i = 0; i < names.size(); i++) {
System.out.println("Name: " + names.get(i));
}
}
我必須使用 var 嗎?不是的,老方法一樣完美支持。
這樣的做法危險(xiǎn)嗎?
一個(gè)字:不。
簡(jiǎn)單說(shuō)它是受限于它們存在的方法(或循環(huán)聲明)的范圍。這意味著除了聲明它們的方法的開(kāi)發(fā)之外,人們不編寫依賴于這些類型的代碼。
還有大家會(huì)有一個(gè)疑惑,很多語(yǔ)言也是不需要定義類型的,完全由編譯器搞定,以 JavaScript 舉例:
var x = "Todd"
簡(jiǎn)單吧,x 是 String 類型的,但是在 JS 中能重新定義類型,比如:
var x = "Todd"
x = 42 // Now it's an int?!
像這種 Java 以后是不是也不用考慮變量類型了?錯(cuò),和JS 不一樣,Java 中的 var 只能在局部變量使用外,同時(shí)是不能重復(fù)賦值的,就拿上面的例子,會(huì)導(dǎo)致編譯錯(cuò)誤:
public void doSomething() {
var x = "Todd";
x = 42; // Compiler fails on this line:
// Error: java: incompatible types: int cannot be converted to java.lang.String
}
所以 var 一點(diǎn)都不危險(xiǎn),Java 也不會(huì)因此變成動(dòng)態(tài)類型分配語(yǔ)言,這僅僅是對(duì)局部變量多了一種定義方式。
總結(jié)下
- Var 是我們的好朋友;
- Java var != JavaScript var;
- Var 解決了你顯示聲明變量的一些麻煩,但他們依然存在;
- Var 聲明的變量和顯示聲明的變量是一模一樣的;
- Var 類型變量不會(huì)影響到你其他的代碼;
- 多了解一下總不會(huì)錯(cuò)吧!
原文鏈接:Java Developers: var Is Your Friend
推薦閱讀:改進(jìn) GitHub 工作流的 15 個(gè)建議