使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
当前回答
它允许你(好吧,编译器)在你重写的方法名上使用了错误的拼写。
其他回答
每当一个方法覆盖了另一个方法,或者一个方法在接口中实现了签名。
@Override注释确保您确实重写了某些内容。如果没有注释,可能会出现拼写错误或参数类型和数字不同的情况。
最好将它用于打算重写的每个方法,以及Java 6+,用于打算作为接口实现的每个方法。
首先,它会在编译时捕获像“hashcode()”而不是“hashcode()”这样的拼写错误。当真正的原因是您的代码从未被调用时,调试为什么您的方法的结果似乎与您的代码不匹配可能会令人困惑。
同样,如果一个超类改变了一个方法签名,旧签名的重写就会被“孤立”,留下令人困惑的死代码。@Override注释将帮助您识别这些孤儿,以便对它们进行修改以匹配新签名。
我总是使用标签。它是一个简单的编译时标志,用于捕捉我可能犯的小错误。
它会捕获tostring()而不是tostring()
小事情有助于大项目。
我认为最好在允许的情况下编写@override。它有助于编码。然而,需要注意的是,对于ecipse Helios,无论是sdk 5还是6,都允许为实现的接口方法使用@override注释。对于Galileo,无论是5还是6,@override注释都不允许。
接口实现上的@Override是不一致的,因为在java中没有“覆盖接口”这样的事情。
@Override on interface implementation is useless since in practise it catches no bugs that the compilation wouldn't catch anyway. There is only one, far fetched scenario where override on implementers actually does something: If you implement an interface, and the interface REMOVES methods, you will be notified on compile time that you should remove the unused implementations. Notice that if the new version of the interface has NEW or CHANGED methods you'll obviously get a compile error anyways as you're not implementing the new stuff.
在1.6中不应该允许接口实现@Override,而不幸的是,eclipse选择自动插入注释作为默认行为,我们得到了大量杂乱的源文件。在阅读1.6代码时,您无法从@Override注释中看出一个方法实际上覆盖了超类中的一个方法,还是仅仅实现了一个接口。
在重写超类中的方法时使用@Override是可以的。