使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
当前回答
最好将它用于打算重写的每个方法,以及Java 6+,用于打算作为接口实现的每个方法。
首先,它会在编译时捕获像“hashcode()”而不是“hashcode()”这样的拼写错误。当真正的原因是您的代码从未被调用时,调试为什么您的方法的结果似乎与您的代码不匹配可能会令人困惑。
同样,如果一个超类改变了一个方法签名,旧签名的重写就会被“孤立”,留下令人困惑的死代码。@Override注释将帮助您识别这些孤儿,以便对它们进行修改以匹配新签名。
其他回答
它所做的另一件事是,当读取代码时,它会更明显地改变父类的行为。这有助于调试。
此外,在Joshua Block的著作《Effective Java》(第二版)中,第36项详细介绍了注释的好处。
每次重写一个方法时使用它有两个好处。这样你就可以利用编译器检查来确保你实际上覆盖了一个方法。这样,如果您犯了拼写错误方法名或没有正确匹配参数的常见错误,您将得到警告,您的方法实际上并没有像您认为的那样重写。其次,它使您的代码更容易理解,因为当方法被覆盖时更明显。
此外,在Java 1.6中,您可以使用它来标记方法何时实现接口,以获得同样的好处。我认为最好有一个单独的注释(如@Implements),但总比没有强。
每当一个方法覆盖了另一个方法,或者一个方法在接口中实现了签名。
@Override注释确保您确实重写了某些内容。如果没有注释,可能会出现拼写错误或参数类型和数字不同的情况。
我总是使用标签。它是一个简单的编译时标志,用于捕捉我可能犯的小错误。
它会捕获tostring()而不是tostring()
小事情有助于大项目。
很简单——当您想重写父类中出现的方法时,使用@Override注释来进行正确的重写。如果你没有正确地覆盖它,编译器会警告你。