使用Java的@Override注释的最佳实践是什么?为什么?

用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?


当前回答

使用@Override注释可以在编译时防止常见的编程错误。它会抛出一个编译错误,如果你在一个方法上有注释,而你实际上没有重写超类方法。

最常见的情况是,当您更改基类中的一个方法以拥有一个不同的参数列表时,这是有用的。子类中用于覆盖超类方法的方法将不再这样做,因为方法签名已更改。这有时会导致奇怪和意外的行为,特别是在处理复杂的继承结构时。@Override注释可以防止这种情况。

其他回答

最佳实践是始终使用它(或让IDE为您填充它们)

@Override有用性是检测父类中没有向下报告的变化。 如果没有@Override,你可以改变方法签名而忘记改变它的覆盖,使用@Override,编译器将为你捕获它。

有这样的安全网总是好的。

如果您发现自己经常重写(非抽象)方法,您可能需要检查一下您的设计。当编译器无法捕捉错误时,它非常有用。例如,尝试在ThreadLocal中覆盖initValue(),这是我已经做过的。

在实现接口方法(1.6+特性)时使用@Override对我来说似乎有点过度。如果你有大量的方法,有些重写了,有些没有,这可能又是糟糕的设计(如果你不知道,你的编辑器可能会显示哪个是哪个)。

@Override注释用于帮助开发人员检查是否重写父类或接口中的正确方法。当super的方法名发生变化时,编译器会通知这种情况,这只是为了与super和子类保持一致。

顺便说一句,如果我们没有在子类中声明注释@Override,但我们重写了super的一些方法,那么这个函数可以像@Override那样工作。但是当super的方法被更改时,这个方法不能通知开发人员。因为它不知道开发人员的目的——重写super的方法还是定义一个新方法?

因此,当我们想要重写该方法以使用多态性时,最好在该方法上方添加@Override。

当你使用Override时要小心,因为你不能在starUML之后做逆向工程;首先制作uml。

最好将它用于打算重写的每个方法,以及Java 6+,用于打算作为接口实现的每个方法。

首先,它会在编译时捕获像“hashcode()”而不是“hashcode()”这样的拼写错误。当真正的原因是您的代码从未被调用时,调试为什么您的方法的结果似乎与您的代码不匹配可能会令人困惑。

同样,如果一个超类改变了一个方法签名,旧签名的重写就会被“孤立”,留下令人困惑的死代码。@Override注释将帮助您识别这些孤儿,以便对它们进行修改以匹配新签名。