Pun打算……讓我們討論Java final 。

最近，我們廣受歡迎的博客文章“編碼Java時(shí)的十個(gè)微妙的最佳實(shí)踐”在JavaWorld的摘要和鏈接中有了很大的復(fù)興，并提出了一組新的評論。 尤其是，JavaWorld編輯對我們對Java關(guān)鍵字“ final ”的觀點(diǎn)提出了質(zhì)疑：

更有爭議的是，Eder提出了默認(rèn)情況下使方法最終化是否安全的問題：

“如果您完全控制所有源代碼，則默認(rèn)情況下將方法定為final絕對沒有問題，因?yàn)?#xff1a;”

• “如果確實(shí)需要重寫方法（真的嗎？），您仍然可以刪除final關(guān)鍵字”
• “您再也不會(huì)意外覆蓋任何方法了”

確實(shí)是的。 默認(rèn)情況下，所有類，方法，字段和局部變量都應(yīng)為final，并且可以通過關(guān)鍵字進(jìn)行更改。

以下是字段和局部變量：

int finalInt = 1; val int finalInt = 2; var int mutableInt = 3;

是否確實(shí)需要使用Scala / C＃樣式的val關(guān)鍵字仍有待商.。 但是很顯然，為了再次修改字段/變量，我們應(yīng)該有一個(gè)明確允許它的關(guān)鍵字。 方法相同–我使用Java 8的default關(guān)鍵字來提高一致性和規(guī)則性：

class FinalClass {void finalMethod() {} }default class ExtendableClass {void finalMethod () {}default void overridableMethod() {} }

在我們看來，那將是一個(gè)完美的世界，但是Java卻采取了另一種方式，將default （可覆蓋，可變）默認(rèn)和final （不可覆蓋，不可變）顯式選項(xiàng)。

公平地說，我們會(huì)忍受的

…作為API設(shè)計(jì)人員（當(dāng)然來自jOOQ API），我們會(huì)很樂意將final放在final ，至少假裝Java具有上述更明智的默認(rèn)值。

但是許多人不同意這種評估，主要原因是：

作為主要在osgi環(huán)境中工作的人，我不能完全同意，但是您可以保證其他api設(shè)計(jì)人員也有同樣的感覺嗎？ 我認(rèn)為最好是先限制api設(shè)計(jì)人員的錯(cuò)誤，而不是先限制用戶可以默認(rèn)擴(kuò)展的范圍，以取代用戶的錯(cuò)誤。 – eliasv在reddit上

要么…

強(qiáng)烈反對。 我寧愿從公共圖書館禁止final和private。 當(dāng)我真的需要擴(kuò)展某些東西而無法完成時(shí)，這是一種痛苦。

故意鎖定代碼可能意味著兩件事，要么糟透了，要么完美。 但是，如果它是完美的，那么沒有人需要對其進(jìn)行擴(kuò)展，那么為什么要關(guān)心它。

當(dāng)然，存在使用final的正當(dāng)理由，但是擔(dān)心用新版本的庫破壞某人并不是其中之一。 – 在reddit上的meotau

還是...

我知道我們已經(jīng)對此進(jìn)行了非常有用的討論，但只是在此線程上提醒其他人：關(guān)于“最終”的許多爭論都取決于上下文：這是公共API還是內(nèi)部代碼？ 在前一種情況下，我同意有一些很好的論據(jù)可以說是最終的。 在后一種情況下，最終幾乎總是一個(gè)糟糕的主意。 – Charles Roth在我們的博客上

所有這些論點(diǎn)都傾向于朝一個(gè)方向發(fā)展：“我們正在開發(fā)糟糕的代碼，因此我們至少需要一些解決方法來減輕這種痛苦。”

但是為什么不這樣想呢：

以上所有人員都想到的API設(shè)計(jì)人員將精確創(chuàng)建您想通過擴(kuò)展進(jìn)行修補(bǔ)的可怕API。 碰巧的是，除非Java語言要求，否則相同的API設(shè)計(jì)人員不會(huì)考慮關(guān)鍵字final的有用性和可通信性，因此永遠(yuǎn)不會(huì)使用它。 雙贏（盡管糟糕的API，不穩(wěn)定的解決方法和補(bǔ)丁程序）。

希望將final用于其API的API設(shè)計(jì)人員將在如何正確設(shè)計(jì)API（以及定義明確的擴(kuò)展點(diǎn)/ SPI）方面反映出很多內(nèi)容，從而使您永遠(yuǎn)不必?fù)?dān)心final是什么。 同樣，雙贏（和一個(gè)很棒的API）。

此外，在后一種情況下，奇怪的黑客將不會(huì)被黑客入侵和破壞您的API，而這只會(huì)導(dǎo)致痛苦和痛苦，但這并不是真正的損失。

最終界面方法

由于上述原因，我仍然深感遺憾，Java 8接口中的final是不可能的。 布萊恩·格茨（Brian Goetz）做出了出色的解釋，為什么如此決定。 實(shí)際上，是通常的解釋。 關(guān)于這一點(diǎn)不是改變的主要設(shè)計(jì)目標(biāo)！

但是，如果我們有以下條件，請考慮語言的一致性和規(guī)律性：

default interface ImplementableInterface {void abstractMethod () ;void finalMethod () {}default void overridableMethod() {} }

_{（鴨子和奔跑…）}

或者，更現(xiàn)實(shí)地說，我們的默認(rèn)值為default ：

interface ImplementableInterface {void abstractMethod () ;final void finalMethod () {}void overridableMethod() {} }

最后

那么，您對此討論的最終想法是什么？

如果您還沒聽夠，請考慮同時(shí)閱讀 Whiley編程語言作者David Pearce博士的 這篇出色文章 。

翻譯自: https://www.javacodegeeks.com/2014/09/this-is-the-final-discussion.html

總結(jié)

以上是生活随笔為你收集整理的这是最后的讨论！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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