你什么时候使用Java的@Override注释？为什么？

Question

你什么时候使用Java的@Override注释？为什么？使用Java @Override注释的最佳实践是什么？为什么？使用@Override注释标记每个重写方法似乎有点过分。是否有某些编程情况需要使用@Override和其他不应该使用的@Override？

Answer 1

每次覆盖一个方法时使用它有两个好处。这样做是为了让您可以利用编译器检查来确保在您认为自己真正重写方法时。这样，如果您犯了一个错误拼写方法名称或者没有正确匹配参数的常见错误，您将收到警告，您的方法实际上并没有像您认为的那样覆盖。其次，它使您的代码更容易理解，因为当覆盖方法时更加明显。

此外，在Java 1.6中，您可以使用它来标记方法何时实现具有相同优点的接口。我认为最好有一个单独的注释（比如@Implements），但它总比没有好。

Answer 2

我认为它最有用的是编译时提醒，方法的意图是覆盖父方法。举个例子：

protected boolean displaySensitiveInformation() {
  return false;}

您经常会看到类似于上述方法的内容，它会覆盖基类中的方法。这是此类的重要实现细节 - 我们不希望显示敏感信息。

假设此方法在父类中更改为

protected boolean displaySensitiveInformation(Context context) {
  return true;}

此更改不会导致任何编译时错误或警告 - 但它会完全更改子类的预期行为。

要回答您的问题：如果缺少超类中具有相同签名的方法指示错误，则应使用@Override注释。

Answer 3

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

编码时没有矫枉过正。键入@override不会花费任何费用，但如果拼写错误的方法名称或签名稍有错误，可能会节省大量成本。

这样考虑一下：当你在这里导航并输入这篇文章的时候，你几乎花了更多的时间，而不是在你的余生中用@foreride打字; 但它阻止的一个错误可以节省你的时间。

Java尽其所能确保您在编辑/编译时没有犯任何错误，这是一种几乎免费的方法来解决在全面测试之外无法以任何其他方式阻止的整类错误。

你能想出一个更好的Java机制来确保当用户想要覆盖一个方法时，他确实做到了吗？

另一个简洁的效果是，如果你不提供注释，它将在编译时警告你，你不小心覆盖了父方法 - 如果你不打算这样做，这可能是重要的。

Answer 4

我总是使用标签。这是一个简单的编译时标志，可以捕获我可能犯的小错误。

它会捕捉到的东西tostring()而不是toString()

小事情有助于大型项目。