我们应该@覆盖接口的方法实现吗?

实现接口方法的方法是否应该用@Override注释?

Override注释的javadoc说:

指示方法声明要重写超类中的方法声明。如果使用此注释类型注释了方法,但没有重写超类方法,则需要编译器生成错误消息。

我不认为接口在技术上是超类。真的是这样吗?

问题细化 .

211508 次浏览

你应该尽可能使用@Override。它可以防止犯简单的错误。例子:

class C {
@Override
public boolean equals(SomeClass obj){
// code ...
}
}

这不能编译,因为它没有正确地覆盖public boolean equals(Object obj)

对于实现接口(仅限1.6及以上)或覆盖超类方法的方法也是如此。

我相信javac的行为已经改变了——在1.5版本中它禁止注释,而在1.6版本中则没有。注释提供了额外的编译时检查,所以如果您使用的是1.6,我会选择它。

重写从您自己的类继承的方法通常不会破坏使用ide进行重构。但是如果您重写从库继承的方法,建议使用它。如果你不这样做,你通常不会在以后的库更改中得到错误,而是一个隐藏得很好的bug。

当你在创建实现接口的类时告诉Eclipse“生成未实现的方法”时,Eclipse本身会添加@Override注释。

对我来说,这通常是一些代码需要Java 6编译的唯一原因。不确定是否值得。

JDK 5.0不允许你在实现interface中声明的方法时使用@Override注释(它的编译错误),但JDK 6.0允许。所以你可以根据自己的需求来设置你的项目偏好。

这对JDK来说不是问题。在Eclipse Helios中,它允许对实现的接口方法使用@Override注释,无论使用哪种JDK 5或6。至于Eclipse Galileo,无论JDK 5还是6,都不允许使用@Override注释。

如果@Override可用,你应该总是用它来注释方法。

在JDK 5中,这意味着重写超类的方法,在JDK 6和7中,这意味着重写超类的方法,并实现接口的方法。原因,如前所述,它允许编译器在您认为您正在重写(或实现)一个方法,但实际上是在定义一个新方法(不同的签名)时捕获错误。

equals(Object)equals(YourObject)的例子是一个标准的例子,但同样的论点也可以用于接口实现。

我想,不强制注释接口的实现方法的原因是JDK 5将其标记为编译错误。如果JDK 6强制使用这个注释,就会破坏向后兼容性。

我不是Eclipse用户,但在其他ide (IntelliJ)中,如果项目设置为JDK 6+项目,则只有在实现接口方法时才会添加@Override注释。我可以想象Eclipse是类似的。

然而,我更希望看到这种用法的不同注释,可能是@Implements注释。

包含@Override的问题是,它会让你认为你忘记调用super.theOverridenMethod()方法,它是非常混乱。这应该是非常清楚的。也许Java应该提供一个@Interface在这里使用。哦,好吧,还有一个半途而废的Java特性……

如果混凝土类不是抽象方法压倒一切的,则对实现使用@Override是一个悬而未决的问题,因为编译器总是会警告你任何未实现的方法。在这些情况下,可以认为它降低了可读性——它在代码中有更多的东西需要阅读,并且在较小的程度上,它被称为@Override而不是@Implement

在java 6及更高版本中,可以使用@Override作为实现接口的方法。

但是,我不认为这是有意义的:覆盖意味着你在超类中有一个方法,而你在子类中实现它。

如果你正在实现一个接口,我认为我们应该使用@Implement或其他东西,而不是@Override

通过读取java8中的javadoc,你可以在接口Override的声明中找到以下内容:

如果一个方法使用这种注释类型进行注释,编译器就需要生成错误消息,除非至少满足以下条件之一:

  • 该方法重写或实现在超类型中声明的方法。
  • 该方法的签名重写等价于在{@linkplain Object}中声明的任何公共方法的签名。

因此,至少在java8中,应该在接口方法的实现上使用@Override。

如果实现interface的类是abstract类,则@Override用于确保实现的是interface方法;如果没有@Override,即使实现方法签名与interface中声明的方法不匹配,abstract类也可以很好地编译;不匹配的interface方法将保持未实现。 @Zhao引用的Java文档

该方法重写或实现在超类型中声明的方法

显然是指abstract超类;interface不能被称为超类型。 因此,@Override是冗余的,对于具体类中的interface方法实现是不合理的

这个回答可能太迟了。但我希望这个例子能帮助人们理解为什么@override如此重要(对于这样的场景)

public interface Restaurant(){
public boolean getBill();
public BigDecimal payAmount();
}


public interface Food() extends Restaurant{
public boolean haveSomeFood();
public boolean drinkWater();
}


public class Hungry() implements Food{
public boolean haveSomeFood(){}
public boolean drinkWater(){}
public boolean getBill(){}
public BigDecimal payAmount(){}
}

在上面的例子中,如果我是Hungry,我可以从Restaurant得到Food。但如果我拿出餐厅的实现,我不需要得到一个账单,也不需要支付金额!!!!

如何? < br >

  • 接口Food有关键字extends Restaurant - which 意味着Hungry类也从接口实现 李餐厅。< / >
  • 方法实际上覆盖了接口 not have关键字@override
  • 因此,如果我删除关键字extends 餐厅(或者说如果我删除接口餐厅,它将不会
  • .显示任何错误

如果有@override,当我试图删除餐厅接口时,它将显示编译错误。

请注意:当你实现一个接口时,你可能不知道这个接口是否被扩展到另一个接口,或者可以被扩展,或者继承可能被删除。因此,最好使用@override关键字