使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
当前回答
仅用于方法声明。 指示带注释的方法 声明覆盖声明 在超类型。
如果持续使用,它可以保护您免受大量恶意漏洞的侵害。
使用@Override注释来避免这些错误: (在以下代码中发现错误:)
public class Bigram {
private final char first;
private final char second;
public Bigram(char first, char second) {
this.first = first;
this.second = second;
}
public boolean equals(Bigram b) {
return b.first == first && b.second == second;
}
public int hashCode() {
return 31 * first + second;
}
public static void main(String[] args) {
Set<Bigram> s = new HashSet<Bigram>();
for (int i = 0; i < 10; i++)
for (char ch = 'a'; ch <= 'z'; ch++)
s.add(new Bigram(ch, ch));
System.out.println(s.size());
}
}
来源:Effective Java
其他回答
使用@Override注释可以在编译时防止常见的编程错误。它会抛出一个编译错误,如果你在一个方法上有注释,而你实际上没有重写超类方法。
最常见的情况是,当您更改基类中的一个方法以拥有一个不同的参数列表时,这是有用的。子类中用于覆盖超类方法的方法将不再这样做,因为方法签名已更改。这有时会导致奇怪和意外的行为,特别是在处理复杂的继承结构时。@Override注释可以防止这种情况。
我认为最好在允许的情况下编写@override。它有助于编码。然而,需要注意的是,对于ecipse Helios,无论是sdk 5还是6,都允许为实现的接口方法使用@override注释。对于Galileo,无论是5还是6,@override注释都不允许。
在实现接口方法时使用@Override完全没有意义。在这种情况下使用它没有任何好处——编译器已经发现了你的错误,所以这只是不必要的混乱。
我认为它在编译时提醒大家,该方法的目的是重写父方法。举个例子:
protected boolean displaySensitiveInformation() {
return false;
}
您将经常看到类似上述方法的内容,它覆盖基类中的方法。这是该类的一个重要实现细节——我们不希望显示敏感信息。
假设这个方法在父类中被更改为
protected boolean displaySensitiveInformation(Context context) {
return true;
}
此更改不会导致任何编译时错误或警告-但它完全改变了子类的预期行为。
回答您的问题:如果在超类中缺少具有相同签名的方法,则表明存在错误,则应该使用@Override注释。
@Override在接口上实际上是有帮助的,因为如果你改变了接口,你会得到警告。