¿Deberíamos @Override la implementación del método de una interfaz?

¿Debería anotarse un método que implementa un método de interfaz con @Override ?

El javadoc de la anotación Override dice:

Indica que una statement de método está destinada a anular una statement de método en una superclase. Si un método se anota con este tipo de anotación pero no anula un método de superclase, los comstackdores deben generar un mensaje de error.

No creo que una interfaz sea técnicamente una superclase. ¿O es eso?

Elaboración de preguntas

Debe usar @Override siempre que sea posible. Evita que se cometan errores simples. Ejemplo:

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

Esto no se comstack porque no anula correctamente los valores public boolean equals(Object obj) .

Lo mismo ocurrirá con los métodos que implementan una interfaz ( 1.6 o superior solamente ) o anula el método de una clase Super.

Creo que el comportamiento de javac ha cambiado: con 1.5 prohibió la anotación, con 1.6 no. La anotación proporciona una verificación adicional en tiempo de comstackción, por lo tanto, si está utilizando 1.6, lo intentaré.

Siempre debe anotar métodos con @Override si está disponible.

En JDK 5 esto significa reemplazar métodos de superclases, en JDK 6, y 7 significa reemplazar métodos de superclases e implementar métodos de interfaces. La razón, como se mencionó anteriormente, es que le permite al comstackdor detectar errores donde cree que está anulando (o implementando) un método, pero en realidad está definiendo un nuevo método (firma diferente).

El ejemplo equals(Object) vs. equals(YourObject) es un caso estándar en el punto, pero el mismo argumento se puede hacer para las implementaciones de interfaz.

Me imagino que la razón por la que no es obligatorio anotar la implementación de métodos de interfaces es que JDK 5 marcó esto como un error de comstackción. Si JDK 6 hizo esta anotación obligatoria, rompería la compatibilidad con versiones anteriores.

No soy un usuario de Eclipse, pero en otros IDEs (IntelliJ), la anotación @Override solo se agrega al implementar métodos de interfaz si el proyecto está configurado como un proyecto JDK 6+. Me imagino que Eclipse es similar.

Sin embargo, hubiera preferido ver una anotación diferente para este uso, tal vez una anotación @Implements .

Lo usaría en cada oportunidad. Consulte ¿ Cuándo utiliza la anotación @Override de Java y por qué?

JDK 5.0 no le permite utilizar la anotación @Override si está implementando el método declarado en la interfaz (su error de comstackción), pero JDK 6.0 lo permite. Entonces puede ser que pueda configurar su preferencia de proyecto de acuerdo a sus requerimientos.

Anular tus propios métodos heredados de tus propias clases normalmente no se romperá en refactorizaciones usando un ide. Pero si anula un método heredado de una biblioteca, se recomienda usarlo. Si no lo haces, a menudo no obtendrás ningún error en un cambio de biblioteca posterior, sino un error bien oculto.

No es un problema con JDK. En Eclipse Helios, permite la anotación @Override para los métodos de interfaz implementados, cualquiera que sea el JDK 5 o 6. En cuanto a Eclipse Galileo, la anotación @Override no está permitida, cualquiera que sea el JDK 5 o 6.

Para mí, muchas veces esta es la única razón por la que algún código requiere la comstackción de Java 6. No estoy seguro de si vale la pena.

Eclipse agregará la anotación @Override cuando le diga que “genere métodos no implementados” durante la creación de una clase que implemente una interfaz.

Si una clase concreta no está anulando un método abstracto, usar @Override para la implementación es una cuestión abierta ya que el comstackdor siempre le advertirá sobre cualquier método no implementado. En estos casos, se puede argumentar que no le permite leer: hay más cosas que leer en el código y, en menor medida, se llama @Override y no @Implement .

El problema con incluir @Override es que te hace pensar que olvidaste llamar al método super.theOverridenMethod() , que es muy confuso . Esto debe ser claro como el cristal. Tal vez Java debería ofrecer una @Interface para ser utilizada aquí. Oh, bueno, otra peculiaridad de Java a medias …

En java 6 y versiones posteriores, puede usar @Override para un método que implementa una interfaz.

Pero, no creo que tenga sentido: anular significa que tienes un método en la superclase, y lo estás implementando en la subclase.

Si está implementando una interfaz, creo que deberíamos usar @Implement u otra cosa, pero no la @Override .

Al leer el javadoc en java8, puede encontrar lo siguiente en la statement de Anulación de la interfaz:

Si un método se anota con este tipo de anotación, los comstackdores deben generar un mensaje de error a menos que se cumplan al menos una de las siguientes condiciones:

  • El método anula o implementa un método declarado en un supertipo.
  • El método tiene una firma que es anulada, equivalente a la de cualquier método público declarado en {@linkplain Object}.

Entonces, al menos en java8, debe usar @Override en una implementación de un método de interfaz.

Para la interfaz, usar @Override provocó un error de comstackción. Entonces, tuve que eliminarlo.

El mensaje de error fue ” The method getAllProducts() of type InMemoryProductRepository must override a superclass method “.

También decía ” One quick fix available: Remove @Override annotation.One quick fix available: Remove @Override annotation.

Fue en Eclipse 4.6.3, JDK 1.8.0_144.