使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
当前回答
这里有很多好的答案,所以让我提供另一种看待它的方式……
编码时没有多余的东西。输入@override不需要花费任何成本,但是如果您拼写错了方法名或签名稍有错误,节省的成本可能是巨大的。
可以这样想:在你浏览这里并输入这篇文章的时间里,你所花费的时间比你余生输入@override的时间还要多;但是它防止的一个错误可以节省你的时间。
Java尽其所能确保您在编辑/编译时不会犯任何错误,这是一种几乎免费的方法来解决整个类型的错误,这些错误在全面测试之外的任何其他方法都无法预防。
你能在Java中提出一种更好的机制来确保当用户想要重写一个方法时,他实际上做到了吗?
另一个巧妙的效果是,如果您不提供注释,它将在编译时警告您不小心覆盖了父方法——如果您不打算这样做,这可能会很重要。
其他回答
注释确实为编译器提供了关于代码的元数据,当我们重写基类的任何方法时,注释@Override用于继承的情况。它只是告诉编译器你正在重写方法。它可以避免一些常见的错误,如没有遵循正确的方法签名或在方法名称上出错等。所以使用@Override注释是一个很好的实践。
最佳实践是始终使用它(或让IDE为您填充它们)
@Override有用性是检测父类中没有向下报告的变化。 如果没有@Override,你可以改变方法签名而忘记改变它的覆盖,使用@Override,编译器将为你捕获它。
有这样的安全网总是好的。
它所做的另一件事是,当读取代码时,它会更明显地改变父类的行为。这有助于调试。
此外,在Joshua Block的著作《Effective Java》(第二版)中,第36项详细介绍了注释的好处。
当你使用Override时要小心,因为你不能在starUML之后做逆向工程;首先制作uml。
很简单——当您想重写父类中出现的方法时,使用@Override注释来进行正确的重写。如果你没有正确地覆盖它,编译器会警告你。