¿Cuándo se utiliza la anotación @Override de Java y por qué?
¿Cuáles son las mejores prácticas para utilizar la anotación de Java @Overridey por qué?
Parece que sería excesivo marcar cada método anulado con la @Overrideanotación. ¿Hay ciertas situaciones de programación que requieren el uso de @Overridey otras que nunca deberían usar el @Override?
Úselo cada vez que anule un método para obtener dos beneficios. Hágalo de modo que pueda aprovechar la verificación del compilador para asegurarse de que realmente está anulando un método cuando cree que es así. De esta manera, si comete el error común de escribir mal el nombre de un método o no hacer coincidir correctamente los parámetros, se le advertirá que su método en realidad no se anula como cree. En segundo lugar, hace que su código sea más fácil de entender porque es más obvio cuando se sobrescriben los métodos.
Además, en Java 1.6 puedes usarlo para marcar cuándo un método implementa una interfaz para obtener los mismos beneficios. Creo que sería mejor tener una anotación separada (como @Implements), pero es mejor que nada.
Creo que es más útil como recordatorio en tiempo de compilación de que la intención del método es anular un método principal. Como ejemplo:
protected boolean displaySensitiveInformation() {
return false;
}
A menudo verá algo como el método anterior que anula un método en la clase base. Este es un detalle de implementación importante de esta clase: no queremos que se muestre información confidencial.
Supongamos que este método se cambia en la clase principal a
protected boolean displaySensitiveInformation(Context context) {
return true;
}
Este cambio no provocará errores ni advertencias en tiempo de compilación, pero cambia por completo el comportamiento previsto de la subclase.
Para responder a su pregunta: debe utilizar la anotación @Override si la falta de un método con la misma firma en una superclase es indicativa de un error.
Hay muchas buenas respuestas aquí, así que permítanme ofrecer otra forma de verlo...
No hay exceso cuando se codifica. No le cuesta nada escribir @override, pero los ahorros pueden ser inmensos si escribe mal el nombre de un método o si la firma es ligeramente incorrecta.
Piénselo de esta manera: en el tiempo que navegó hasta aquí y escribió esta publicación, utilizó prácticamente más tiempo del que dedicará a escribir @override por el resto de su vida; pero un error que previene puede ahorrarle horas.
Java hace todo lo posible para asegurarse de que no haya cometido ningún error en el momento de la edición/compilación; esta es una forma prácticamente gratuita de resolver una clase completa de errores que no se pueden prevenir de ninguna otra manera fuera de las pruebas exhaustivas.
¿Podrías idear un mecanismo mejor en Java para garantizar que cuando el usuario pretendía anular un método, realmente lo hiciera?
Otro efecto interesante es que si no proporciona la anotación, le advertirá en el momento de la compilación que accidentalmente anuló un método principal, algo que podría ser importante si no tenía la intención de hacerlo.
