¿Realmente necesitamos @Override y demás cuando codificamos Java? [duplicate]

Posible duplicado:

¿Cuándo usa la anotación @Override de Java y por qué?

Me pregunto cuál es la funcionalidad de agregar @Override delante del código que nos gustaría anular es. Lo he hecho con y sin él, y parecía que todo iba bien (al menos, a mí).

No lo es necesario, pero es muy recomendable. Evita que te dispares en el pie. Ayuda a prevenir el caso cuando escribe una función que cree que anula a otra pero escribió algo mal y obtiene un comportamiento completamente inesperado.

cuál es la funcionalidad de agregar @Override

Permite que el compilador vuelva a verificar por usted cuando dice (mediante anotaciones) que se supone que un método específico anula un método de superclase (o implementa un método de interfaz en Java 6 o posterior). Si el método, de hecho, no anula un método de superclase (o implementa un método de interfaz), el compilador lo marcará como un error. Esto a menudo indica que tiene un error tipográfico en el nombre del método o que cometió un error en la firma del método.

¿Realmente necesitamos @Override?

¿Necesito? Absolutamente no, pero es tal barato manera de

• transmite explícitamente al lector humano que este es un método primordial, y
• atrapa un error en tiempo de compilación eso podría tomar al menos algunos ciclos cerebrales para detectar en tiempo de ejecución una vez que sepas buscarlo

… e incluso más barato cuando su IDE lo está ayudando a incluirlo …

Se recomienda ya que ayuda a administrar la consistencia. Imagina que alguien cambiará el nombre del método de la superclase (y solo allí, sin realizar cambios de nombre en las clases dependiendo de ello, lo cual es bastante hipotético :)), entonces serás el primero en saberlo debido a errores de compilación.

La única diferencia sería que si anota un método con @Override y no está anulando nada, el compilador se quejará.

Verifique ¿Cuándo usa la anotación de anulación de Java y por qué?

Me ha ayudado un buen par de veces a evitar errores ortográficos/diferencias entre mayúsculas y minúsculas en los nombres de los métodos. Sin él, es uno de esos molestos errores que pueden tardar años en localizarse.

No agrega ninguna diferencia funcional, pero decirle al compilador que cree que está anulando un método para que pueda quejarse si no lo está es muy útil cuando ha cometido un error en alguna parte.

Es muy recomendable usarlo, ya que aumenta la incomprensión de su código y ayuda a otros a mantener su código también.

Personalmente, no creo que sea útil, excepto para los IDE que realizan la verificación de errores en tiempo de compilación, pero esa es mi opinión. Razón: supongamos que tienes

Class A { 
    methodName() { System.out.println ("A"); }
}

class B extends A { 
    methodName() { System.out.println ("B"); }
}

En tiempo de ejecución, probablemente llamará a B.methodName(); a B no le importa si B.methodName() anula el mismo nombre de la clase A(). Para la clase B, ni siquiera debería importar si la superclase (A) implementa methodName(). Lo que quiero decir es que la herencia es una calle de sentido único: no puede desheredar algo usando un @override; todo lo que el compilador puede verificar es si hay un método con la misma firma en la superclase, que no se usará de todos modos .

Para las otras respuestas, si alguien edita A.java para eliminar o cambiar el nombre de methodName() o cambiar su firma, aún puede llamar a B.methodName() sin problemas, pero solo si no usa ese @override. Creo que también es por eso que es no una parte del lenguaje Java.