使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
当前回答
当你使用Override时要小心,因为你不能在starUML之后做逆向工程;首先制作uml。
其他回答
我认为它在编译时提醒大家,该方法的目的是重写父方法。举个例子:
protected boolean displaySensitiveInformation() {
return false;
}
您将经常看到类似上述方法的内容,它覆盖基类中的方法。这是该类的一个重要实现细节——我们不希望显示敏感信息。
假设这个方法在父类中被更改为
protected boolean displaySensitiveInformation(Context context) {
return true;
}
此更改不会导致任何编译时错误或警告-但它完全改变了子类的预期行为。
回答您的问题:如果在超类中缺少具有相同签名的方法,则表明存在错误,则应该使用@Override注释。
覆盖注释用于利用编译器,用于检查是否实际上覆盖了父类中的方法。如果你犯了任何错误,比如拼写错误的方法名,没有正确匹配参数的错误,它被用来通知
这里有很多好的答案,所以让我提供另一种看待它的方式……
编码时没有多余的东西。输入@override不需要花费任何成本,但是如果您拼写错了方法名或签名稍有错误,节省的成本可能是巨大的。
可以这样想:在你浏览这里并输入这篇文章的时间里,你所花费的时间比你余生输入@override的时间还要多;但是它防止的一个错误可以节省你的时间。
Java尽其所能确保您在编辑/编译时不会犯任何错误,这是一种几乎免费的方法来解决整个类型的错误,这些错误在全面测试之外的任何其他方法都无法预防。
你能在Java中提出一种更好的机制来确保当用户想要重写一个方法时,他实际上做到了吗?
另一个巧妙的效果是,如果您不提供注释,它将在编译时警告您不小心覆盖了父方法——如果您不打算这样做,这可能会很重要。
当你使用Override时要小心,因为你不能在starUML之后做逆向工程;首先制作uml。
使用@Override注释可以在编译时防止常见的编程错误。它会抛出一个编译错误,如果你在一个方法上有注释,而你实际上没有重写超类方法。
最常见的情况是,当您更改基类中的一个方法以拥有一个不同的参数列表时,这是有用的。子类中用于覆盖超类方法的方法将不再这样做,因为方法签名已更改。这有时会导致奇怪和意外的行为,特别是在处理复杂的继承结构时。@Override注释可以防止这种情况。