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

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

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

“如果您完全控制所有源代碼，則默認情況下將方法定為final絕對沒有問題，因為：”

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

確實是的。 默認情況下，所有類，方法，字段和局部變量都應為final，并且可以通過關鍵字進行更改。

以下是字段和局部變量：

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

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

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

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

公平地說，我們會忍受的

…作為API設計人員（當然來自jOOQ API），我們會很樂意將final放在final ，至少假裝Java具有上述更明智的默認值。

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

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

要么…

強烈反對。 我寧愿從公共圖書館禁止final和private。 當我真的需要擴展某些東西而無法完成時，這是一種痛苦。

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

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

還是...

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

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

但是為什么不這樣想呢：

以上所有人員都想到的API設計人員將精確創建您想通過擴展進行修補的可怕API。 碰巧的是，除非Java語言要求，否則相同的API設計人員不會考慮關鍵字final的有用性和可通信性，因此永遠不會使用它。 雙贏（盡管糟糕的API，不穩定的解決方法和補丁程序）。

希望將final用于其API的API設計人員將在如何正確設計API（以及定義明確的擴展點/ SPI）方面反映出很多內容，從而使您永遠不必擔心final是什么。 同樣，雙贏（和一個很棒的API）。

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

最終界面方法

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

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

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

_{（鴨子和奔跑…）}

或者，更現實地說，我們的默認值為default ：

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

最后

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。