使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
使用Java的@Override注释的最佳实践是什么?为什么?
用@Override注释标记每个被重写的方法似乎有点过分。是否有某些编程情况需要使用@Override,而其他情况不应该使用@Override?
当前回答
我认为最好在允许的情况下编写@override。它有助于编码。然而,需要注意的是,对于ecipse Helios,无论是sdk 5还是6,都允许为实现的接口方法使用@override注释。对于Galileo,无论是5还是6,@override注释都不允许。
其他回答
为了从编译器检查中获益,你应该总是使用Override注释。但是不要忘记Java Compiler 1.5在覆盖接口方法时不允许这个注释。您只能使用它来重写类方法(抽象与否)。
有些ide(如Eclipse)甚至配置了Java 1.6运行时或更高版本,它们保持与Java 1.5的一致性,并且不允许像上面描述的那样使用@override。要避免这种行为,您必须转到:项目属性->Java编译器->勾选“启用项目特定设置”->选择“编译器遵从级别”= 6.0或更高。
我喜欢在每次独立重写方法时使用这个注释,如果基是一个接口或类。
这可以帮助您避免一些典型的错误,例如当您认为您正在重写事件处理程序时,然后您没有看到发生任何事情。假设你想给某个UI组件添加一个事件监听器:
someUIComponent.addMouseListener(new MouseAdapter(){
public void mouseEntered() {
...do something...
}
});
上面的代码编译并运行,但是如果你将鼠标移动到someUIComponent内部,“do something”代码将提示运行,因为实际上你没有覆盖基本方法mouseEntered(MouseEvent ev)。您只需创建一个新的无参数方法mouseEntered()。如果您使用了@Override注释,那么您将看到一个编译错误,并且没有浪费时间思考为什么事件处理程序没有运行。
我总是使用标签。它是一个简单的编译时标志,用于捕捉我可能犯的小错误。
它会捕获tostring()而不是tostring()
小事情有助于大项目。
它允许你(好吧,编译器)在你重写的方法名上使用了错误的拼写。
每次重写一个方法时使用它有两个好处。这样你就可以利用编译器检查来确保你实际上覆盖了一个方法。这样,如果您犯了拼写错误方法名或没有正确匹配参数的常见错误,您将得到警告,您的方法实际上并没有像您认为的那样重写。其次,它使您的代码更容易理解,因为当方法被覆盖时更明显。
此外,在Java 1.6中,您可以使用它来标记方法何时实现接口,以获得同样的好处。我认为最好有一个单独的注释(如@Implements),但总比没有强。
这里有很多好的答案,所以让我提供另一种看待它的方式……
编码时没有多余的东西。输入@override不需要花费任何成本,但是如果您拼写错了方法名或签名稍有错误,节省的成本可能是巨大的。
可以这样想:在你浏览这里并输入这篇文章的时间里,你所花费的时间比你余生输入@override的时间还要多;但是它防止的一个错误可以节省你的时间。
Java尽其所能确保您在编辑/编译时不会犯任何错误,这是一种几乎免费的方法来解决整个类型的错误,这些错误在全面测试之外的任何其他方法都无法预防。
你能在Java中提出一种更好的机制来确保当用户想要重写一个方法时,他实际上做到了吗?
另一个巧妙的效果是,如果您不提供注释,它将在编译时警告您不小心覆盖了父方法——如果您不打算这样做,这可能会很重要。