用var聲明變量，在java中竟然有這麼多細節，你都瞭解麼？

時間 2020-08-05

標籤 var 聲明變量 java 竟然有這細節瞭解欄目 Java 简体版

原文原文鏈接

簡介

Java SE 10引入了局部變量的類型推斷。早先，全部的局部變量聲明都要在左側聲明明確類型。使用類型推斷，一些顯式類型能夠替換爲具備初始化值的局部變量保留類型var，這種做爲局部變量類型的var類型，是從初始化值的類型中推斷出來的。java

關於此功能存在必定的爭議。有些人對它的簡潔性表示歡迎，其餘人則擔憂它剝奪了閱讀者看重的類型信息，從而損害了代碼的可讀性。這兩邊觀點都是對的。它能夠經過消除冗餘信息使代碼更具備可讀性，也能夠經過刪除有用的信息來下降代碼的可讀性。另一個觀點是擔憂它會被濫用，從而致使編寫更糟糕的Java代碼。這也是事實，但它也可能會致使編寫更好的代碼。像全部功能同樣，使用它必需要判斷。什麼時候該使用，什麼時候不應使用，沒有一系列規則。程序員

局部變量聲明不是孤立存在的；周邊的代碼能夠影響甚至壓倒使用var的影響。本文檔的目的是檢查周邊代碼對var聲明的影響，解釋一些權衡，並提供有效使用var的指南。面試

使用原則算法

P1. 閱讀代碼比編寫代碼更重要

代碼的讀取頻率遠高於編寫代碼。此外，在編寫代碼時，咱們一般要有總體思路，而且要花費時間；在閱讀代碼的時候，咱們常常是上下文瀏覽，並且可能更加匆忙。是否以及如何使用特定語言功能應該取決於它對將來讀者的影響，而不是它的做者。較短的程序可能比較長的程序更可取，可是過多地簡寫程序會省略對於理解程序有用的信息。這裏的核心問題是爲程序找到合適的大小，以便最大化程序的可讀性。spring

咱們在這裏特別關注在輸入或編寫程序時所須要的碼字量。雖然簡潔性可能會是對做者的一個很好的鼓勵，但專一於它會忽略主要的目標，即提升程序的可讀性。數據庫

P2. 在通過局部變量類型推斷後，代碼應該變得清晰

讀者應該可以查看var聲明，而且使用局部變量聲明的時候能夠馬上了解代碼里正在發生了什麼事情。理想狀況下，只經過代碼片斷或上下文就能夠輕鬆理解代碼。若是讀懂一個var聲明須要讀者去查看代碼周邊的若干位置代碼，此時使用var可能不是一個好的狀況。並且，它還代表代碼自己可能存在問題。編程

P3. 代碼的可讀性不該該依賴於IDE

代碼一般在IDE中編寫和讀取，因此很容易依賴IDE的代碼分析功能。對於類型聲明，在任何地方使用var,均可以經過IDE指向一個變量來肯定它的類型，可是爲何不這麼作呢？設計模式

這裏有兩個緣由。代碼常常在IDE外部讀取。代碼出如今IDE設施不可用的許多地方，例如文檔中的片斷，瀏覽互聯網上的倉庫或補丁文件。爲了理解這些代碼的做用，你必須將代碼導入IDE。這樣作是拔苗助長的。緩存

第二個緣由是即便是在IDE中讀取代碼時也是如此，一般須要明確的操做來查詢IDE以獲取有關變量的更多信息。例如，查詢使用var聲明的變量類型，可能必須將鼠標懸停在變量上並等待彈出信息，這可能只須要片刻時間，可是它會擾亂閱讀流程。網絡

代碼應該是自動呈現的，它的表面應該是能夠理解的，而且無需工具的幫助。

P4. 顯式類型是一種權衡

Java從來要求局部變量聲明裏要明確包含顯式類型，顯然顯式類型可能很是有用，但它們有時候不是很重要，有時候還能夠忽略。要求一個明確的類型可能還會混亂一些有用的信息。

省略顯式類型能夠減小這種混亂，但只有在這種混亂不會損害其可理解性的狀況下。這種類型不是向讀者傳達信息的惟一方式。其餘方法包括變量的名稱和初始化表達式也能夠傳達信息。在肯定是否能夠將其中一個頻道靜音時，咱們應該考慮全部可用的頻道。

指南
G1. 選擇可以提供有用信息的變量名稱
一般這是一個好習慣，不過在var的背景下它更爲重要。在一個var的聲明中，可使用變量的名稱來傳達有關變量含義和用法的信息。使用var替換顯式類型的同時也要改進變量的名稱。例如：

//原始寫法
List<Customer> x = dbconn.executeQuery(query);

//改進寫法
var custList = dbconn.executeQuery(query);

在這種狀況下，無用的變量名x已被替換爲一個可以喚起變量類型的名稱custList，該名稱如今隱含在var的聲明中。根據方法的邏輯結果對變量的類型進行編碼，得出了」匈牙利表示法」形式的變量名custList。就像顯式類型同樣，這樣有時是有幫助的，有時候只是雜亂無章。在此示例中，名稱custList表示正在返回List。這也可能不重要。和顯式類型不一樣，變量的名稱有時能夠更好地表達變量的角色或性質，好比」customers」:

//原始寫法    
try (Stream<Customer> result = dbconn.executeQuery(query)) {
     return result.map(...)
                  .filter(...)
                  .findAny();
 }
//改進寫法
try (var customers = dbconn.executeQuery(query)) {
    return customers.map(...)
                    .filter(...)
                    .findAny();
}

G2.最小化局部變量的使用範圍
最小化局部變量的範圍一般也是一個好的習慣。這種作法在 Effective Java (第三版)，第57項中有所描述。若是你要使用var，它會是一個額外的助力。

在下面的例子中，add方法正確地將特殊項添加到list集合的最後一個元素，因此它按照預期最後處理。

var items = new ArrayList<Item>(...);
items.add(MUST_BE_PROCESSED_LAST);
for (var item : items) ...

如今假設爲了刪除重複的項目，程序員要修改此代碼以使用HashSet而不是ArrayList：

var items = new HashSet<Item>(...);
items.add(MUST_BE_PROCESSED_LAST);
for (var item : items) ...

這段代碼如今有個bug，由於Set沒有定義迭代順序。不過，程序員可能會當即修復這個bug，由於items變量的使用與其聲明相鄰。

如今假設這段代碼是一個大方法的一部分，相應地items變量具備很大的使用範圍：

var items = new HashSet<Item>(...);

// ... 100 lines of code ...

items.add(MUST_BE_PROCESSED_LAST);
for (var item : items) ...

將ArrayList更改成HashSet的影響再也不明顯，由於使用items的代碼與聲明items的代碼離得很遠。這意味着上面所說的bug彷佛能夠存活更長時間。

若是items已經明確聲明爲List，還須要更改初始化程序將類型更改成Set。這可能會提示程序員檢查方法的其他部分是否存在受此類更改影響的代碼。(問題來了，他也可能不會檢查)。若是使用var會消除這類影響，不過也可能會增長在此類代碼中引入錯誤的風險。

這彷佛是反對使用var的論據，但實際上並不是如此。使用var的初始化程序很是精簡。僅當變量的使用範圍很大時纔會出現此問題。你應該更改代碼來減小局部變量的使用範圍，而後用var聲明它們，而不是簡單地避免在這些狀況下使用var。

G3. 當初始化程序爲讀者提供足夠的信息時，請考慮使用var
局部變量一般在構造函數中進行初始化。正在建立的構造函數名稱一般與左側顯式聲明的類型重複。若是類型名稱很長，就可使用var提高簡潔性而不會丟失信息：

// 原始寫法：
ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
// 改進寫法
var outputStream = new ByteArrayOutputStream();

在初始化程序是方法調用的狀況下，使用var也是合理的，例如靜態工廠方法，而且其名稱包含足夠的類型信息：

//原始寫法
BufferedReader reader = Files.newBufferedReader(...);
List<String> stringList = List.of("a", "b", "c");
// 改進寫法
var reader = Files.newBufferedReader(...);
var stringList = List.of("a", "b", "c");

在這些狀況下，方法的名稱強烈暗示其特定的返回類型，而後用於推斷變量的類型。

G4. 使用var局部變量分解鏈式或嵌套表達式
考慮使用字符串集合並查找最常出現的字符串的代碼，可能以下所示：

return strings.stream()
               .collect(groupingBy(s -> s, counting()))
               .entrySet()
               .stream()
               .max(Map.Entry.comparingByValue())
               .map(Map.Entry::getKey);

這段代碼是正確的，但它可能使人困惑，由於它看起來像是一個單一的流管道。事實上，它先是一個短暫的流，接着是第一個流的結果生成的第二個流，而後是第二個流的可選結果映射後的流。表達此代碼的最易讀的方式是兩個或三個語句；第一組實體放入一個Map,而後第二組過濾這個Map，第三組從Map結果中提取出Key，以下所示：

Map<String, Long> freqMap = strings.stream()
                                   .collect(groupingBy(s -> s, counting()));
Optional<Map.Entry<String, Long>> maxEntryOpt = freqMap.entrySet()
                                                       .stream()
                                                       .max(Map.Entry.comparingByValue());
return maxEntryOpt.map(Map.Entry::getKey);

但編寫者可能會拒絕這樣作，由於編寫中間變量的類型彷佛太過於繁瑣，相反他們篡改了控制流程。使用var容許咱們更天然地表達代碼，而無需付出顯式聲明中間變量類型的高代價：

var freqMap = strings.stream()
                     .collect(groupingBy(s -> s, counting()));
var maxEntryOpt = freqMap.entrySet()
                         .stream()
                         .max(Map.Entry.comparingByValue());
return maxEntryOpt.map(Map.Entry::getKey);

有些人可能更傾向於第一段代碼中單個長的鏈式調用。可是，在某些條件下，最好分解長的方法鏈。對這些狀況使用var是一種可行的方法，而在第二個段中使用中間變量的完整聲明會是一個很差的選擇。和許多其餘狀況同樣，正確使用var可能會涉及到扔掉一些東西（顯示類型）和加入一些東西（更好的變量名稱，更好的代碼結構）。

G5. 不用過度擔憂」使用接口編程」中局部變量的使用問題

Java編程中常見的習慣用法是構造具體類型的實例，但要將其分配給接口類型的變量。這將代碼綁定到抽象上而不是具體實現上，爲代碼之後的維護保留了靈活性。

//原始寫法, list類型爲接口List類型
List<String> list = new ArrayList<>()

若是使用var,能夠推斷出list具體的實現類型ArrayList而不是接口類型List

// 推斷出list的類型是 ArrayList<String>.
var list = new ArrayList<String>();

這裏要再次重申一次，var只能用於局部變量。它不能用於推斷屬性類型，方法參數類型和方法返回類型。」使用接口編程」的原則在這些狀況下仍然和以往同樣重要。

主要問題是使用該變量的代碼能夠造成對具體實現的依賴性。若是變量的初始化程序之後要改變，這可能致使其推斷類型發生變化，在使用該變量的後續代碼中產生異常或bug。

若是，如指南G2中所建議的那樣，局部變量的範圍很小，可能影響後續代碼的具體實現的」漏洞」是有限的。若是變量僅用於幾行以外的代碼，應該很容易避免這些問題或者緩解這些出現的問題。

在這種特殊狀況下，ArrayList只包含一些不在List上的方法，如ensureCapacity()和trimToSize()。這些方法不會影響到List,因此調用他們不會影響程序的正確性。這進一步下降了推斷類型做爲具體實現類型而不是接口類型的影響。

G6. 使用帶有<>和泛型方法的var時候要當心

var和<>功能容許您在能夠從已存在的信息派生時，省略具體的類型信息。你能在同一個變量聲明中使用它們嗎？

考慮一下如下代碼：

PriorityQueue<Item> itemQueue = new PriorityQueue<Item>();

這段代碼可使用var或<>重寫，而且不會丟失類型信息:

// 正確：兩個變量均可以聲明爲PriorityQueue<Item>類型
PriorityQueue<Item> itemQueue = new PriorityQueue<>();
var itemQueue = new PriorityQueue<Item>();

同時使用var和<>是合法的，但推斷類型將會改變：

// 危險: 推斷類型變成了 PriorityQueue<Object>
var itemQueue = new PriorityQueue<>();

從上面的推斷結果來看，<>可使用目標類型（一般在聲明的左側）或構造函數做爲<>裏的參數類型。若是二者都不存在，它會追溯到最寬泛的適用類型，一般是Object。這一般不是咱們預期的結果。

泛型方法早已經提供了類型推斷，使用泛型方法不多須要提供顯式類型參數，若是是沒有提供足夠類型信息的實際方法參數，泛型方法的推斷就會依賴於目標類型。在var聲明中沒有目標類型，因此也會出現相似的問題。例如：

// 危險: list推斷爲 List<Object>
var list = List.of();

使用<>和泛型方法，能夠經過構造函數或方法的實際參數提供其餘類型信息，容許推斷出預期的類型，從而有：

// 正確: itemQueue 推斷爲 PriorityQueue<String>
Comparator<String> comp = ... ;
var itemQueue = new PriorityQueue<>(comp);

// 正確: infers 推斷爲 List<BigInteger>
var list = List.of(BigInteger.ZERO);

若是你想要將var與<>或泛型方法一塊兒使用，你應該確保方法或構造函數參數可以提供足夠的類型信息，以便推斷的類型與你想要的類型匹配。不然，請避免在同一聲明中同時使用var和<>或泛型方法。

G7.使用基本類型的var要當心

基本類型可使用var聲明進行初始化。在這些狀況下使用var不太可能提供不少優點，由於類型名稱一般很短。不過，var有時候也頗有用，例如，可使變量的名稱對齊。

boolean,character,long,string的基本類型使用var沒有問題，這些類型的推斷是精確的，由於var的含義是明確的

// 原始作法
boolean ready = true;
char ch = '\ufffd';
long sum = 0L;
String label = "wombat";

// 改進作法
var ready = true;
var ch    = '\ufffd';
var sum   = 0L;
var label = "wombat";

當初始值是數字時，應該特別當心，特別是int類型。若是左側有顯示類型，那麼右側會經過向上或向下轉型將int數值默默轉爲左邊對應的類型。若是左邊使用var，那麼右邊的值會被推斷爲int類型。這多是無心的。

// 原始作法
byte flags = 0;
short mask = 0x7fff;
long base = 17;

// 危險: 全部的變量類型都是int
var flags = 0;
var mask = 0x7fff;
var base = 17;

若是初始值是浮點型，推斷的類型大可能是明確的：

// 原始作法
float f = 1.0f;
double d = 2.0;

// 改進作法
var f = 1.0f;
var d = 2.0;

注意，float類型能夠默默向上轉型爲double類型。使用顯式的float變量（如3.0f）爲double變量作初始化會有點遲鈍。不過，若是是使用var對double變量用float變量作初始化，要注意：

// 原始作法
static final float INITIAL = 3.0f;
...
double temp = INITIAL;

// 危險: temp被推斷爲float類型了
var temp = INITIAL;

（實際上，這個例子違反了G3準則，由於初始化程序裏沒有提供足夠的類型信息能讓讀者明白其推斷類型。）

示例

本節包含一些示例，這些例子中使用var能夠收到良好的效果。

下面這段代碼表示的是根據最多匹配數max從一個Map中移除匹配的實體。通配符（?）類型邊界能夠提升方法的靈活性，可是長度會很長。不幸的是，這裏Iterator的類型還被要求是一個嵌套的通配符類型，這樣使它的聲明更加的冗長，以致於for循環標題長度在一行裏都放不下。也使代碼更加的難懂。

// 原始作法
void removeMatches(Map<? extends String, ? extends Number> map, int max) {
    for (Iterator<? extends Map.Entry<? extends String, ? extends Number>> iterator =
             map.entrySet().iterator(); iterator.hasNext();) {
        Map.Entry<? extends String, ? extends Number> entry = iterator.next();
        if (max > 0 &amp;&amp; matches(entry)) {
            iterator.remove();
            max--;
        }
    }
}

在這裏使用var就能夠刪除掉局部變量一些干擾的類型聲明。在這種循環中顯式的類型Iterator,Map.Entry在很大程度上是沒有必要的，
使用var聲明就可以讓for循環標題放在同一行。代碼也更易懂。

// 改進作法
void removeMatches(Map<? extends String, ? extends Number> map, int max) {
    for (var iterator = map.entrySet().iterator(); iterator.hasNext();) {
        var entry = iterator.next();
        if (max > 0 &amp;&amp; matches(entry)) {
            iterator.remove();
            max--;
        }
    }
}

考慮使用try-with-resources語句從Socket讀取單行文本的代碼。網絡和IO類通常都是裝飾類。在使用時，必須將每一箇中間對象聲明爲資源變量，以便在打開後續的裝飾類的時候可以正確關閉這個資源。常規編寫代碼要求在變量左右聲明重複的類名，這樣會致使不少混亂：

// 原始作法
try (InputStream is = socket.getInputStream();
     InputStreamReader isr = new InputStreamReader(is, charsetName);
     BufferedReader buf = new BufferedReader(isr)) {
    return buf.readLine();
}

使用var聲明會減小不少這種混亂：

// 改進作法
try (var inputStream = socket.getInputStream();
     var reader = new InputStreamReader(inputStream, charsetName);
     var bufReader = new BufferedReader(reader)) {
    return bufReader.readLine();
}