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

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


当前回答

这里有很多好的答案,所以让我提供另一种看待它的方式……

编码时没有多余的东西。输入@override不需要花费任何成本,但是如果您拼写错了方法名或签名稍有错误,节省的成本可能是巨大的。

可以这样想:在你浏览这里并输入这篇文章的时间里,你所花费的时间比你余生输入@override的时间还要多;但是它防止的一个错误可以节省你的时间。

Java尽其所能确保您在编辑/编译时不会犯任何错误,这是一种几乎免费的方法来解决整个类型的错误,这些错误在全面测试之外的任何其他方法都无法预防。

你能在Java中提出一种更好的机制来确保当用户想要重写一个方法时,他实际上做到了吗?

另一个巧妙的效果是,如果您不提供注释,它将在编译时警告您不小心覆盖了父方法——如果您不打算这样做,这可能会很重要。

其他回答

覆盖注释用于利用编译器,用于检查是否实际上覆盖了父类中的方法。如果你犯了任何错误,比如拼写错误的方法名,没有正确匹配参数的错误,它被用来通知

@Override在接口上实际上是有帮助的,因为如果你改变了接口,你会得到警告。

我认为最好在允许的情况下编写@override。它有助于编码。然而,需要注意的是,对于ecipse Helios,无论是sdk 5还是6,都允许为实现的接口方法使用@override注释。对于Galileo,无论是5还是6,@override注释都不允许。

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

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

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

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

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

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