使用Java的@Override注释的最佳实践是什么，为什么？
用@Override注释标记每个被覆盖的方法似乎是多余的。 是否有某些编程情况要求使用@Override而另一些则永远不要使用@Override ？
#1楼
接口实现上的@Override是不一致的，因为在Java中没有“覆盖接口”之类的东西。
@Override在接口实现上是没有用的，因为在实践中它不会捕获编译无论如何都不会捕获的错误。 只有一种牵强附会的情况，实现者的重写实际上会做一些事情：如果您实现一个接口，并且该接口使用REMOVES方法，则将在编译时通知您应删除未使用的实现。 请注意，如果新版本的接口具有NEW或CHANGED方法，则显然您将获得编译错误，因为您没有实现新的东西。
在1.6中，绝对不应在接口实现程序上使用@Override，并且由于eclipse不幸地选择将注释自动插入为默认行为，因此，我们得到了很多混乱的源文件。 在阅读1.6代码时，您无法从@Override注释中看到某个方法是否实际上覆盖了超类中的方法或仅实现了一个接口。
在实际重写超类中的方法时使用@Override很好。
#2楼
要利用编译器检查的优势，您应该始终使用Override注释。 但是请不要忘记，当重写接口方法时，Java Compiler 1.5将不允许此注释。 您仅可以使用它来覆盖类方法（是否抽象）。
某些IDE（例如Eclipse）甚至配置了Java 1.6运行时或更高版本，它们仍然符合Java 1.5，并且不允许如上所述使用@override。 为了避免这种行为，您必须转到：项目属性-> Java编译器->选中“启用项目特定设置”->选择“编译器符合级别” = 6.0或更高。
如果基础是接口或类，我每次独立重写方法时都喜欢使用此批注。
这可以帮助您避免一些典型的错误，例如当您以为您要覆盖事件处理程序，然后什么也没看到时。 假设您要向某个UI组件添加事件侦听器：
someUIComponent.addMouseListener(new MouseAdapter(){
public void mouseEntered() {
...do something...
}
});
上面的代码可以编译并运行，但是如果将鼠标移到someUIComponent内，则“执行某些操作”代码将记录运行情况，因为实际上您没有覆盖基本方法mouseEntered(MouseEvent ev) 。 您只需创建一个新的无参数方法mouseEntered() 。 代替该代码，如果您使用@Override批注，则会看到编译错误，而您并没有在浪费时间思考为什么事件处理程序未运行。
#3楼
- 仅用于方法声明。
- 指示带注释的方法声明将覆盖超类型中的声明。
如果持续使用，它将保护您免受各种恶意错误的侵害。
使用@Override注释可避免这些错误：（在以下代码中发现该错误：）
public class Bigram {
private final char first;
private final char second;
public Bigram(char first, char second) {
this.first = first;
this.second = second;
}
public boolean equals(Bigram b) {
return b.first == first && b.second == second;
}
public int hashCode() {
return 31 * first + second;
}
public static void main(String[] args) {
Set<Bigram> s = new HashSet<Bigram>();
for (int i = 0; i < 10; i++)
for (char ch = 'a'; ch <= 'z'; ch++)
s.add(new Bigram(ch, ch));
System.out.println(s.size());
}
}
来源： 有效的Java
#4楼
似乎这里的智慧正在改变。 今天，我安装了IntelliJ IDEA 9，并且注意到它的“ 缺少@Override检查 ”现在不仅捕获了实现的抽象方法，还捕获了实现的接口方法。 在我的雇主的代码库和我自己的项目中，我长期以来习惯只对前一种方法使用@Override －实现抽象方法。 但是，重新考虑这种习惯，在两种情况下使用注释的好处就变得很明显。 尽管更为冗长，但它确实可以防止接口方法名称更改的脆弱基类问题（不像C ++相关示例那样严重），在派生类中孤立了将要实现的方法。
当然，这种情况大都是夸张的。 派生类将不再编译，现在缺少重命名的接口方法的实现，如今，人们可能会使用“ 重命名方法”重构操作来批量处理整个代码库。
鉴于无法将IDEA的检查配置为忽略已实现的接口方法，所以今天我将改变我的习惯和团队的代码审查标准。
#5楼
简单–当您要覆盖超类中存在的方法时，请使用@Override批注进行正确的覆盖。 如果您没有正确覆盖它，编译器会警告您。
#6楼
在实现接口方法时，使用@Override绝对没有任何意义。 在这种情况下使用它没有优势-编译器已经捕获了您的错误，因此这只是不必要的混乱。
#7楼
使用Override时要小心，因为之后不能在starUML中进行反向工程； 首先使uml。
#8楼
覆盖注释用于利用编译器的优势，用于检查您是否实际上是从父类覆盖方法。 它用于通知您是否犯了任何错误，例如拼写错误的方法名称，不正确匹配参数的错误。
#9楼
我认为最好在允许的情况下对@override进行编码。 它有助于编码。 但是，需要注意的是，对于密钥Helios（sdk 5或6），允许使用已实现的接口方法的@override注释。 对于Galileo，无论是5还是6，都不允许@override注释。
#10楼
我尽可能地使用它来标识何时重写方法。 如果您查看Scala编程语言，它们还具有override关键字。 我觉得这很有用。
#11楼
批注确实向编译器提供了有关代码的元数据，并且当我们重写基类的任何方法时，在继承的情况下使用批注@Override。 它只是告诉编译器您正在重写方法。 它可以避免某些常见错误，例如我们不遵循方法的正确签名或方法名称中的拼写错误等。因此，使用@Override注释是一种很好的做法。
#12楼
注释@Override用于帮助检查开发人员是否在父类或接口中重写正确的方法。 当super的方法名称更改时，编译器可以通知这种情况，这仅是为了与super和子类保持一致。
顺便说一句，如果我们没有在子类中声明注解@Override，但是我们确实重写了super的某些方法，则该函数可以与@Override一起使用。 但是，当更改超级方法时，此方法无法通知开发人员。 因为它不知道开发者的目的-覆盖super的方法还是定义新的方法？
因此，当我们想重写该方法以利用多态性时，最好在该方法上方添加@Override。
#13楼
对我来说，@ Override确保我拥有正确的方法签名。 如果我在批注中添加了该方法，并且该方法的拼写不正确，则编译器会抱怨让我知道某些错误。
#14楼
我每次都用它。 在一年中重新访问代码时，我可以使用它来快速了解发生了什么，而我已经忘记了第一次的想法。
#15楼
我总是使用标签。 这是一个简单的编译时标志，用于捕获我可能犯的小错误。
它将捕获诸如tostring()而不是toString()
小事情对大型项目有帮助。
#16楼
每当一个方法重写另一个方法，或者某个方法在接口中实现签名时。
@Override注释可确保您确实覆盖了某些内容。 如果没有注释，则可能会拼写错误或参数类型和数量有所不同。
#17楼
当您在要覆盖的方法名称上使用了错误的拼写时，它确实使您（编译器）可以捕获。
#18楼
每次您重写一种方法都有两个好处时使用它。 这样做是为了使您能够利用编译器检查的优势，以确保您认为自己确实覆盖了某个方法。 这样，如果您犯了拼写错误的方法名称或不正确匹配参数的常见错误，将会警告您方法实际上并没有像您认为的那样覆盖。 其次，它使您的代码更易于理解，因为当方法被覆盖时，它更加明显。
另外，在Java 1.6中，您可以使用它来标记方法何时实现接口以实现相同的好处。 我认为最好有一个单独的注释（例如@Implements ），但总比没有好。
#19楼
使用@Override注释可作为编译时保护措施，以防止常见的编程错误。 如果您在实际上未覆盖超类方法的方法上具有注释，则将引发编译错误。
最有用的情况是在基类中更改方法以具有不同的参数列表时。 子类中用于重写超类方法的方法将不再这样做，因为方法签名已更改。 这有时会导致奇怪和意外的行为，尤其是在处理复杂的继承结构时。 @Override注释可以防止这种情况。
#20楼
如果您发现自己经常重写（非抽象）方法，则可能要看一下您的设计。 当编译器否则无法捕获该错误时，这将非常有用。 例如，尝试覆盖ThreadLocal中的initValue（），我已经完成了。
在实现接口方法（1.6+功能）时使用@Override对我来说有点矫kill过正。 如果您有大量的方法，其中有些方法会被覆盖，而有些方法则不会，那么设计可能又很糟糕（如果您不知道，您的编辑器可能会显示哪个方法）。
#21楼
最好的方法是始终使用它（或让IDE为您填充它们）
@Override的用途是检测尚未在层次结构中报告的父类中的更改。 没有它，您可以更改方法签名，而忘记更改其覆盖，使用@Override，编译器会为您捕获它。
拥有这样的安全网永远都是好事。
#22楼
我认为最有用的是作为编译时提醒，该方法的意图是重写父方法。 举个例子：
protected boolean displaySensitiveInformation() {
return false;
}
您会经常看到类似上述方法的内容，该方法会覆盖基类中的方法。 这是此类的重要实现细节-我们不希望显示敏感信息。
假设将此方法在父类中更改为
protected boolean displaySensitiveInformation(Context context) {
return true;
}
此更改不会导致任何编译时错误或警告-但它会完全更改子类的预期行为。
要回答您的问题：如果在超类中缺少具有相同签名的方法表明存在错误，则应使用@Override批注。
#23楼
实际上，对接口进行@Override很有帮助，因为如果更改接口，则会收到警告。
#24楼
我到处都用它。 关于标记方法的工作，我让Eclipse为我做，因此，这无需额外的工作。
我信奉持续重构...。因此，我将尽一切努力使它更加顺利。
#25楼
最好将其用于所有打算用作覆盖的方法，以及Java 6+，每个打算用作接口实现的方法。
首先，它在编译时捕获了诸如“ hashcode() ”而不是“ hashCode() ”之类的拼写错误。 当真正的原因是您的代码从未被调用时，调试为什么您的方法的结果似乎与您的代码不匹配可能令人困惑。
此外，如果超类更改了方法签名，则较旧的签名的覆盖可能会“孤立”，并留下混乱的死代码。 @Override注释将帮助您识别这些孤儿，以便可以对其进行修改以匹配新签名。
#26楼
这里有很多很好的答案，所以让我提供另一种看待它的方法...
编写代码时，不要过度杀伤力。 键入@override不会花费任何费用，但是如果您拼写错误的方法名称或使签名略有错误，则可以节省大量资金。
这样想：在您浏览此处并键入此帖子时，您花费的时间几乎比一生中花费@override花费的时间多得多； 但是它可以防止一个错误，从而节省您的时间。
Java会竭尽所能，以确保您在编辑/编译时没有犯任何错误，这实际上是一种免费的方法，可以解决一整套错误，而这些错误在综合测试之外是无法避免的。
您能否在Java中提出一种更好的机制，以确保当用户打算重写某个方法时，他确实做到了？
另一个很好的效果是，如果您不提供注释，它将在编译时警告您不小心覆盖了父方法-如果您不打算这样做，则这可能很重要。
#27楼
它所做的另一件事是，在阅读代码时，它将更明显地改变了父类的行为。 比可以帮助调试。
另外，在Joshua Block的书《 Effective Java（第二版）》中，第36项提供了有关注释好处的更多细节。
