自檢：

變量聲明之后是否有立即賦值，集合聲明之后是否有立即添加元素

存在的問題：

變量的聲明和賦值分離帶來的問題就是，把賦值的過程與業(yè)務(wù)處理混雜在一起。

編程規(guī)則：

變量要一次性完成初始化

應(yīng)對(duì)策略：

• 1.在聲明前面加上final，用不變性的限制約束代碼。
• 2.用聲明式的方式進(jìn)行集合的初始化。
  • 傳統(tǒng)的集合初始化方式是命令式的，而我們要做的就是用聲明式的方式進(jìn)行集合的初始化，讓初始化的過程一次性完成。再進(jìn)一步，以聲明式的標(biāo)準(zhǔn)來看代碼，會(huì)幫助我們發(fā)現(xiàn)許多的。

1. 變量的初始化

EpubStatus status = null;
CreateEpubResponse response = createEpub(request);
if (response.getCode() == 201) {
    status = EpubStatus.CREATED;
} else {
    status = EpubStatus.TO_CREATE;
}

上面的代碼，從語義上說，第一行的變量初始化其實(shí)是沒有用的，這是一次假的初始化。這段代碼里的變量賦值是在聲明很久之后才完成的，也就是說，變量初始化沒有一次性完成。

這種代碼真正的問題就是不清晰，變量初始化與業(yè)務(wù)處理混在在一起。通常來說，這種代碼后面緊接著就是一大堆更復(fù)雜的業(yè)務(wù)處理。很多代碼難讀，一個(gè)重要的原因就是把不同層面的代碼混在了一起。

這種代碼在實(shí)際的代碼庫(kù)中出現(xiàn)的頻率非常高，只不過，它會(huì)以各種變形的方式呈現(xiàn)出來。有的變量甚至是在相隔很遠(yuǎn)的地方才做了真正的賦值，完成了初始化，這中間已經(jīng)夾雜了很多的業(yè)務(wù)代碼在其中，進(jìn)一步增加了理解的復(fù)雜度。所以，我們編程時(shí)要有一個(gè)基本原則：變量一次性完成初始化。

final CreateEpubResponse response = createEpub(request);
final EpubStatus status = toEpubStatus(response);
private EpubStatus toEpubStatus(final CreateEpubResponse response) {
    if (response.getCode() == 201) {
        return EpubStatus.CREATED;
    }
    return EpubStatus.TO_CREATE;
}

在這段改進(jìn)的代碼中，我們提取出了一個(gè)函數(shù)，將 response 轉(zhuǎn)成對(duì)應(yīng)的內(nèi)部的 EPUB 狀態(tài)。

還有一點(diǎn)不知道你注意到了沒有，在新的變量聲明中，我加上了 final，在 Java 的語義中，一個(gè)變量加上了 final，也就意味著這個(gè)變量不能再次賦值。盡可能編寫不變的代碼，盡可能使用不變的量。所以，在能夠使用 final 的地方盡量使用 final，限制變量的賦值。

對(duì)于 Java 程序員來說，還有一個(gè)特殊的場(chǎng)景，就是異常處理的場(chǎng)景，強(qiáng)迫你把變量的聲明與初始化分開，就像下面這段代碼：

InputStream is = null;
try {
    is = new FileInputStream(...);
    ...
} catch (IOException e) {
    ...
} finally {
    if (is != null) {
        is.close();
    }
}

如果采用 Java 7 之后的版本，采用 try-with-resource 的寫法，代碼就可以更簡(jiǎn)潔了：

try (InputStream is = new FileInputStream(...)) {
    ...
}

2. 集合的初始化

List<Permission> permissions = new ArrayList<>();
permissions.add(Permission.BOOK_READ);
permissions.add(Permission.BOOK_WRITE);
check.grantTo(Role.AUTHOR, permissions);

這和我們前面所說的變量先聲明后賦值，本質(zhì)上是一回事，都是從一個(gè)變量的聲明到初始化成一個(gè)可用的狀態(tài)，中間隔了太遠(yuǎn)的距離。

我們可以使用 Guava（Google 提供的一個(gè) Java 庫(kù)）進(jìn)行修改優(yōu)化：

List<Permission> permissions = ImmutableList.of(
Permission.BOOK_READ,
Permission.BOOK_WRITE
);
check.grantTo(Role.AUTHOR, permissions);

這段代碼里的 List 用的是一個(gè) ImmutableList，也就是一個(gè)不可變的 List，也就是說，這個(gè) List 一旦創(chuàng)建好了，就是不能修改了，對(duì)應(yīng)的實(shí)現(xiàn)就是各種添加、刪除之類的方法全部都禁用了。

針對(duì)Map同樣有類似的用法：

private static Map<Locale, String> CODE_MAPPING = ImmutableMap.of(
LOCALE.ENGLISH, "EN",
LOCALE.CHINESE, "CH"
);

對(duì)比我們改造前后的代碼，二者之間還有一個(gè)更關(guān)鍵的區(qū)別：前面的代碼是命令式的代碼，而后面的代碼是聲明式的代碼。

命令式的代碼，就是告訴你“怎么做”的代碼，就像改造前的代碼，聲明一個(gè)集合，然后添加一個(gè)元素，再添加一個(gè)元素。而聲明式的代碼，是告訴你“做什么”的代碼，改造后就是，我要一個(gè)包含了這兩個(gè)元素的集合。

聲明式的代碼體現(xiàn)的意圖，是更高層面的抽象，把意圖和實(shí)現(xiàn)分開，從某種意義上來說，也是一種分離關(guān)注點(diǎn)。所以，用聲明式的標(biāo)準(zhǔn)來看代碼，是一個(gè)發(fā)現(xiàn)代碼的重要參考。

以上就是java變量的聲明與賦值分離規(guī)范示例的詳細(xì)內(nèi)容，更多關(guān)于java變量的聲明與賦值分離的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論