所謂的最不起眼的事情如何導(dǎo)致爭(zhēng)議性的討論，有時(shí)甚至導(dǎo)致激烈的辯論激烈，這不是很有趣嗎？ 例如，我目睹了幾次場(chǎng)合，如何使用關(guān)鍵字final引發(fā)了非常激烈的爭(zhēng)論。 對(duì)于一個(gè)外部觀察者來說，這看起來似乎是對(duì)邪惡或神圣的最終決定stake可危。

但是，必須公平地說，大多數(shù)可能的final用例很難適應(yīng)簡(jiǎn)單的對(duì)或錯(cuò)模式。 使用還是不使用的選擇取決于經(jīng)常矛盾的個(gè)人強(qiáng)調(diào)。

在文學(xué)中尋求建議時(shí)，唯一的中途共識(shí)似乎是最終常數(shù)定義…

class Foo {public static final String CONSTANT = "constantValue"; }

…和約書亞·布洛赫（Joshua Bloch）的第15項(xiàng)：最小化可變性¹ ，他建議將不可變類的所有字段都定型為final并確保不能擴(kuò)展該類（而后者不必通過final強(qiáng)制實(shí)現(xiàn)）：

public final class Foo {private final int value;public Foo( int value) {this.value = value;}public int getValue() {return value;}[...] }

從那里意見分歧。 小羅伯特·西蒙斯 在他的《 Hardcore Java ^2》一書中，整整一章都專門介紹了final關(guān)鍵字，他在結(jié)尾給出了強(qiáng)烈的建議：“將final遍及整個(gè)代碼”。 這個(gè)寫得很好的章節(jié)包含許多關(guān)于通過聲明變量，參數(shù)，方法或類final將邏輯錯(cuò)誤轉(zhuǎn)換為編譯時(shí)錯(cuò)誤的優(yōu)點(diǎn)的見解。

另一方面，羅伯特·C·馬丁（Robert C. Martin）明確不同意以下陳述：“有一些對(duì)final良好用法，例如偶爾的final常數(shù)，但否則關(guān)鍵字幾乎沒有價(jià)值，而且會(huì)造成很多混亂” ³ 。 他繼續(xù)說， final可能會(huì)遇到的錯(cuò)誤類型通常會(huì)在他的單元測(cè)試中涵蓋。

雖然我傾向于同意馬丁，但我不會(huì)說席夢(mèng)思通常是錯(cuò)的。 過去，我實(shí)際上經(jīng)常自己使用final關(guān)鍵字，以避免編程錯(cuò)誤或?yàn)E用。 但是，改變主意的原因之一可能是幾年前我轉(zhuǎn)向TDD方法。

通過這樣做，除馬丁的論點(diǎn)之外，我注意到，如果將協(xié)作者類或其某些方法聲明為final ，則通過協(xié)作者模擬實(shí)現(xiàn)測(cè)試隔離變得更加棘手。 由于很難將測(cè)試視為濫用 ，這使我想到了此類聲明可能暗示的深遠(yuǎn)影響。 我意識(shí)到，很難預(yù)見到將沒有有效的用例，這將證明擴(kuò)展和覆蓋是合理的。

相反，面對(duì)final方法或類，人們有時(shí)會(huì)頗具創(chuàng)造力，以某種方式規(guī)避了限制，使事情可能比例如類擴(kuò)展本來就糟。 因此，如今，我通常避免在類和方法聲明上使用關(guān)鍵字，而將自己局限于文檔中不希望出現(xiàn)的子類注釋或類似內(nèi)容。

在本文結(jié)束之前，我想就上述混亂的話題分享最后的想法。 為此，請(qǐng)查看以下代碼，該代碼依賴final來確定方法范圍的變量和參數(shù)：

public void doit( final String message ) {final int value = calculate();final Item item = create( value, message );executorService.submit( new Runnable() {public void run() {handle( item );}} );}

盡管代碼沒有多大用處，并且可以進(jìn)行不同的排列，但是對(duì)于最近偶然遇到的final 代碼 ，它反映了一些實(shí)際的編碼風(fēng)格 。 盡管這種樣式可以防止在發(fā)生意外時(shí)重新分配局部變量，但它也掩蓋了一個(gè)事實(shí)，即final聲明實(shí)際上是強(qiáng)制性的。 這是因?yàn)樵谀涿鸕unnable實(shí)現(xiàn)中使用了變量item 。 下一個(gè)代碼片段擺脫了不必要的聲明以強(qiáng)調(diào)不同之處：

public void doit( String message ) {int value = calculate();final Item item = create( value, message );executorService.submit( new Runnable() {public void run() {handle( item );}} );}

權(quán)衡利弊我更喜歡最后一個(gè)變體，但我假設(shè)根據(jù)您個(gè)人的觀點(diǎn)，IDE的功能是通過警告退出本地重新協(xié)助的能力，團(tuán)隊(duì)的編碼約定以及，而且，而且，您可能會(huì)有充分的理由選擇第一種或第二種樣式，甚至更傾向于選擇兩者的混合。

這使我得出最終結(jié)論，那就是爭(zhēng)論將繼續(xù)下去！

有效的Java（第二版），第4章–類和接口，Joshua Bloch，2008年， ?

頑固的Java，第2章-最后的故事，小羅伯特·西蒙斯，2004年， ?

干凈的代碼，第16章，重構(gòu)SerialDate，羅伯特·C·馬丁，2009年?

翻譯自: https://www.javacodegeeks.com/2014/04/java-code-style-the-final-decision.html

總結(jié)

以上是生活随笔為你收集整理的Java代码风格：最终决定的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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