multiple - java註解




你什麼時候使用Java的@Override註解,為什麼? (18)

使用Java的@Override註釋的最佳實踐是什麼?為什麼?

@Override註解來標記每一個重寫的方法似乎是過度的。 是否有某些編程情況需要使用@Override和其他不應使用@Override編程?


@Override 接口實現不一致,因為在java中沒有“覆蓋接口”這樣的東西。

@Override 接口的實現是沒有用的,因為實際上它沒有捕捉到編譯無法捕捉的錯誤。 只有一個很重要的場景,其中對實現者的重寫實際上會做某些事情:如果實現一個接口和接口REMOVES方法,將在編譯時通知您應該刪除未使用的實現。 注意,如果新版本的接口有NEW或CHANGED方法,那麼顯然你會得到一個編譯錯誤,因為你沒有實現新的東西。

@Override接口實現者應該永遠不會被允許在1.6中,並且在eclipse中可悲地選擇將註釋自動插入為默認行為時,我們會得到很多混亂的源文件。 讀取1.6代碼時,如果某個方法實際上覆蓋了超類中的某個方法或僅實現了一個接口,則無法從@Override註釋中看到該代碼。

在實際重寫超類中的方法時使用@Override是沒有問題的。


@Override接口實際上是有幫助的,因為如果你改變接口你會得到警告。


使用覆蓋時要小心,因為之後不能在starUML中執行逆向工程; 首先製作uml。


在實現接口方法時使用@Override絕對沒有意義。 在這種情況下使用它沒有什麼好處 - 編譯器已經可以解決你的錯誤,所以這只是不必要的混亂。


它所做的另一件事是它在閱讀代碼時更加明顯,它正在改變父類的行為。 比可以幫助調試。

另外,在Joshua Block的Effective Java(第二版)一書中,第36項給出了關於註釋優點的更多細節。


它確實允許你(當然,編譯器)在你使用重寫的方法名稱時使用了錯誤的拼寫。


我到處使用它。 關於標記方法努力的話題,我讓Eclipse為我做了這些,這不是額外的努力。

我對連續重構有宗教信仰......所以,我會利用每一件小事讓它更順利。


我每次都用它。 當我重新訪問一年的代碼時,我可以利用這些信息快速了解發生了什麼,並且我已經忘記了我第一次想到的內容。


我總是使用標籤。 這是一個簡單的編譯時標誌,可以捕捉我可能犯的一些小錯誤。

它會捕獲像tostring()而不是toString()

這些小東西有助於大型項目。


我認為最好在允許的情況下編寫@override。 它有助於編碼。 然而,要注意的是,對於ecipse Helios,sdk 5或6,允許實現的接口方法的@override註釋。 至於Galileo,無論是5還是6,@override註釋都是不允許的。


最好將它用於每個旨在用作覆蓋的方法,以及用於實現接口的每種方法Java 6+。

首先,它在編譯時捕獲拼寫錯誤,如“ hashcode() ”而不是“ hashCode() ”。 當真正的原因是您的代碼從未被調用時,調試您的方法的結果似乎與您的代碼不匹配的原因可能會令人困惑。

另外,如果超類更改了方法簽名,則舊簽名的覆蓋可能會“孤立”,留下作為令人困惑的死代碼。 @Override註釋將幫助您識別這些孤兒,以便可以修改它們以匹配新簽名。


最好的方法是始終使用它(或者讓IDE為你填充它們)

@Override的用處是檢測父類的變化,這些變化還沒有在層次結構中報告。 如果沒有它,你可以改變一個方法簽名,忘記用@Override來改變它的覆蓋,編譯器會為你捕獲它。

這種安全網總是有好處的。


每當一個方法重寫另一個方法,或者一個方法在接口中實現一個簽名。

@Override註釋保證你確實覆蓋了某些東西。 如果沒有註釋,可能會導致拼寫錯誤或參數類型和編號有所不同。


為了從編譯器檢查中獲益,應始終使用Override註釋。 但是不要忘記,在重寫接口方法時,Java編譯器1.5不會允許這個註釋。 你可以使用它來覆蓋類方法(抽像或不抽象)。

一些IDE,比如Eclipse,甚至配置了Java 1.6運行時或更高版本,它們保持與Java 1.5的兼容性,並且不允許如上所述使用@override。 要避免這種行為,您必須轉到:Project Properties - > Java Compiler - >選中“Enable Project Specific Settings” - >選擇“Compiler Compliance Level”= 6.0或更高版本。

如果基礎是接口或類,我喜歡每次獨立重寫一個方法時使用此註釋。

這可以幫助你避免一些典型的錯誤,比如當你認為你重寫了一個事件處理程序,然後你什麼都看不到。 想像一下,你想添加一個事件監聽器到一些UI組件:

someUIComponent.addMouseListener(new MouseAdapter(){
  public void mouseEntered() {
     ...do something...
  }
});

上面的代碼編譯並運行,但是如果將鼠標移動到someUIComponent中,則“執行某些”代碼將會注意運行,因為實際上您不覆蓋基本方法mouseEntered(MouseEvent ev) 。 您只需創建一個新的無參數方法mouseEntered() 。 而不是那個代碼,如果你使用了@Override註解,你已經看到了一個編譯錯誤,並且你沒有浪費時間思考你的事件處理程序為什麼沒有運行。


簡單 - 當您想要覆蓋超類中存在的方法時,請使用@Override註釋來進行正確的覆蓋。 如果你沒有正確覆蓋它,編譯器會警告你。


覆蓋註釋用於利用編譯器,用於檢查是否實際上是從父類重寫方法。 它用於通知您是否發生錯誤拼寫錯誤的方法名稱錯誤,沒有正確匹配參數的錯誤


註釋確實向編譯器提供了有關代碼的元數據,並且當我們重寫基類的任何方法時,在繼承時使用註釋@Override。 它只是告訴編譯器你正在重寫方法。 它可以避免我們可以做的一些常見錯誤,比如不遵循方法的正確簽名或者方法名稱的錯誤等等,所以它是使用@Override註釋的一個好習慣。


這裡有很多很好的答案,所以讓我提供另一種方式來看看它...

編碼時不會出現矯枉過正的情況。 輸入@override並不需要花費任何東西,但如果拼寫錯誤的方法名稱或簽名稍微錯誤,節省的成本可能非常大。

這樣想:當你在這裡瀏覽並鍵入這篇文章的時候,你會花費更多的時間,而不是在你的餘生中輸入@override; 但它阻止的一個錯誤可以節省您的時間。

Java盡其所能確保您在編輯/編譯時沒有犯任何錯誤,這是一種幾乎完全免費的方式來解決在全面測試之外無法以任何其他方式避免的一整類錯誤。

你能想出一個更好的Java機制來確保當用戶打算重寫一個方法時,他實際上做了什麼?

另一個巧妙的結果是,如果你不提供註釋,它會在編譯時警告你意外地超越了父級方法 - 如果你不打算這樣做,這可能很重要。







annotations