java implementacion - ¿Debemos anular la implementación del método de una interfaz?




las ejercicios (13)

Para la interfaz, el uso de @Override provocó un error de compilación. Por lo tanto, tuve que quitarlo.

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

También se lee " One quick fix available: Remove @Override annotation. " One quick fix available: Remove @Override annotation.

Estaba en Eclipse 4.6.3, JDK 1.8.0_144.

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

El javadoc de la anotación de Override dice:

Indica que una declaración de método está destinada a anular una declaración 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 compiladores deben generar un mensaje de error.

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

Elaboración de la pregunta


La anulación de sus propios métodos heredados de sus propias clases no se usará para refactorizar el uso de un ide. Pero si reemplaza un método heredado de una biblioteca, se recomienda utilizarlo. Si no lo hace, a menudo no obtendrá ningún error en un cambio posterior de la biblioteca, sino un error bien oculto.


Si una clase concreta no está anulando un método abstracto, usar @Override para la implementación es un asunto abierto ya que el compilador le avisará invariablemente de cualquier método no implementado. En estos casos, se puede argumentar que resta valor a la legibilidad: hay más cosas que leer en su código y, en menor grado, se llama @Override y no @Implement .


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

Si se anota un método con este tipo de anotación, los compiladores deben generar un mensaje de error a menos que se cumpla 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.


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

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

Esto no se compila porque no reemplaza correctamente a public boolean equals(Object obj) .

Lo mismo se aplicará a los métodos que implementan una interfaz (solo la versión 1.6 o superior ) o anulan el método de una Super clase.


JDK 5.0 no le permite usar la anotación @Override si está implementando un método declarado en la interfaz (su error de compilación), pero JDK 6.0 lo permite. Por lo tanto, puede configurar su preferencia de proyecto de acuerdo con sus requerimientos.


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 compilación, por lo que si está usando 1.6, me gustaría hacerlo.


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 compilador detectar errores cuando cree que está anulando (o implementando) un método, pero en realidad está definiendo un nuevo método (firma diferente).

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

Me imagino que la razón por la que no es obligatorio anotar los métodos de implementación de las interfaces es que JDK 5 marcó esto como un error de compilación. Si JDK 6 hizo esta anotación obligatoria, rompería la compatibilidad hacia atrás.

No soy un usuario de Eclipse, pero en otros IDE (IntelliJ), la anotación @Override solo se agrega al implementar métodos de interfaz si el proyecto se configura 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 de @Implements .



Para mí, muchas veces esta es la única razón por la que algún código requiere Java 6 para compilar. 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 implementa una interfaz.


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

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

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


¿Por qué usar SerialVersionUIDdentro de Serializableclase en Java?

Durante serialization, el tiempo de ejecución de Java crea un número de versión para una clase, de modo que pueda dessializarlo más tarde. Este número de versión se conoce como SerialVersionUIDen Java.

SerialVersionUIDSe utiliza para la versión de datos serializados. Solo puede des-serializar una clase si SerialVersionUIDcoincide con la instancia serializada. Cuando no declaramos SerialVersionUIDen nuestra clase, el tiempo de ejecución de Java lo genera para nosotros, pero no es recomendable. Se recomienda declarar SerialVersionUIDcomo private static final longvariable para evitar el mecanismo por defecto.

Cuando declara una clase Serializableimplementando una interfaz de marcador java.io.Serializable, el tiempo de ejecución de Java conserva la instancia de esa clase en el disco utilizando el mecanismo de serialización predeterminado, siempre que no haya personalizado el proceso utilizando la Externalizableinterfaz.

vea también Por qué usar SerialVersionUID dentro de la clase Serializable en Java

Código: javassist.SerialVersionUID





java oop interface annotations