使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
当前回答
很简单——当您想重写父类中出现的方法时,使用@Override注释来进行正确的重写。如果你没有正确地覆盖它,编译器会警告你。
其他回答
如果您发现自己经常重写(非抽象)方法,您可能需要检查一下您的设计。当编译器无法捕捉错误时,它非常有用。例如,尝试在ThreadLocal中覆盖initValue(),这是我已经做过的。
在实现接口方法(1.6+特性)时使用@Override对我来说似乎有点过度。如果你有大量的方法,有些重写了,有些没有,这可能又是糟糕的设计(如果你不知道,你的编辑器可能会显示哪个是哪个)。
@Override注释用于帮助开发人员检查是否重写父类或接口中的正确方法。当super的方法名发生变化时,编译器会通知这种情况,这只是为了与super和子类保持一致。
顺便说一句,如果我们没有在子类中声明注释@Override,但我们重写了super的一些方法,那么这个函数可以像@Override那样工作。但是当super的方法被更改时,这个方法不能通知开发人员。因为它不知道开发人员的目的——重写super的方法还是定义一个新方法?
因此,当我们想要重写该方法以使用多态性时,最好在该方法上方添加@Override。
我认为它在编译时提醒大家,该方法的目的是重写父方法。举个例子:
protected boolean displaySensitiveInformation() {
return false;
}
您将经常看到类似上述方法的内容,它覆盖基类中的方法。这是该类的一个重要实现细节——我们不希望显示敏感信息。
假设这个方法在父类中被更改为
protected boolean displaySensitiveInformation(Context context) {
return true;
}
此更改不会导致任何编译时错误或警告-但它完全改变了子类的预期行为。
回答您的问题:如果在超类中缺少具有相同签名的方法,则表明存在错误,则应该使用@Override注释。
很简单——当您想重写父类中出现的方法时,使用@Override注释来进行正确的重写。如果你没有正确地覆盖它,编译器会警告你。
注释确实为编译器提供了关于代码的元数据,当我们重写基类的任何方法时,注释@Override用于继承的情况。它只是告诉编译器你正在重写方法。它可以避免一些常见的错误,如没有遵循正确的方法签名或在方法名称上出错等。所以使用@Override注释是一个很好的实践。