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

¿Cuáles son las mejores prácticas para usar la @Overrideanotación de Java y por qué?

Parece que sería excesivo marcar cada método anulado con la @Overrideanotación. ¿Existen 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 para que pueda aprovechar la comprobación del compilador para asegurarse de que realmente está anulando un método cuando cree que lo está haciendo. De esta manera, si comete un error común de escribir mal el nombre de un método o no coincide correctamente con los parámetros, se le advertirá que su método no se anula realmente 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 puede 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 padre a

protected boolean displaySensitiveInformation(Context context) {
  return true;
}

Este cambio no provocará errores o advertencias en tiempo de compilación, pero cambia por completo el comportamiento previsto de la subclase.

Para responder a su pregunta: debe usar la anotación @Override si la falta de un método con la misma firma en una superclase es indicativo de un error.

Aquí hay muchas buenas respuestas, así que permítanme ofrecerles otra forma de verlo ...

No hay exageración cuando estás codificando. No le cuesta nada escribir @override, pero los ahorros pueden ser inmensos si escribe mal el nombre de un método o se equivocó un poco en la firma.

Piénsalo de esta manera: en el tiempo que navegaste aquí y escribiste esta publicación, prácticamente utilizaste más tiempo del que pasarías escribiendo @override por el resto de tu vida; pero un error que evita puede ahorrarle horas.

Java hace todo lo posible para asegurarse de que no cometió ningún error en el tiempo de edición / compilación, esta es una forma prácticamente gratuita de resolver una clase completa de errores que no se pueden evitar de ninguna otra manera fuera de las pruebas exhaustivas.

¿Podría encontrar un mejor mecanismo en Java para asegurarse de que cuando el usuario intenta anular un método, realmente lo hizo?

Otro efecto positivo es que si no proporciona la anotación, le advertirá en el momento de la compilación que anuló accidentalmente un método principal, algo que podría ser significativo si no tuviera la intención de hacerlo.

Yo siempre uso la etiqueta. Es un indicador de tiempo de compilación simple para detectar pequeños errores que podría cometer.

Atrapará cosas como en tostring()lugar detoString()

Las pequeñas cosas ayudan en grandes proyectos.

El uso de la @Overrideanotación actúa como una protección en tiempo de compilación contra un error de programación común. Lanzará un error de compilación si tiene la anotación en un método que realmente no está anulando el método de superclase.

El caso más común en el que esto es útil es cuando está cambiando un método en la clase base para tener una lista de parámetros diferente. Un método en una subclase que solía anular el método de la superclase ya no lo hará debido a la firma del método modificado. Esto a veces puede causar un comportamiento extraño e inesperado, especialmente cuando se trata de estructuras de herencia complejas. La @Overrideanotación protege contra esto.

Para aprovechar la verificación del compilador, siempre debe usar la anulación de anulación. Pero no olvide que Java Compiler 1.5 no permitirá esta anotación al anular los métodos de interfaz. Solo puede usarlo para anular los métodos de clase (abstractos o no).

Algunos IDE, como Eclipse, incluso configurados con Java 1.6 runtime o superior, mantienen el cumplimiento con Java 1.5 y no permiten el uso @override como se describe anteriormente. Para evitar ese comportamiento, debe ir a: Propiedades del proyecto -> Compilador Java -> Marque “Habilitar configuraciones específicas del proyecto” -> Elija “Nivel de cumplimiento del compilador” = 6.0 o superior.

Me gusta usar esta anotación cada vez que anulo un método de forma independiente, si la base es una interfaz o clase.

Esto le ayuda a evitar algunos errores típicos, como cuando piensa que está anulando un controlador de eventos y luego no ve que sucede nada. Imagine que desea agregar un detector de eventos a algún componente de la interfaz de usuario:

someUIComponent.addMouseListener(new MouseAdapter(){
  public void mouseEntered() {
     ...do something...
  }
});

El código anterior se compila y se ejecuta, pero si mueve el mouse dentro de algún componente UIC, el código "hacer algo" indicará ejecutar, porque en realidad no está anulando el método base mouseEntered(MouseEvent ev). Simplemente crea un nuevo método sin parámetros mouseEntered(). En lugar de ese código, si ha utilizado la @Overrideanotación, ha visto un error de compilación y no ha perdido el tiempo pensando por qué su controlador de eventos no se estaba ejecutando.

@Override en la implementación de la interfaz es inconsistente ya que no existe tal cosa como "anular una interfaz" en Java.

@Override en la implementación de la interfaz es inútil ya que en la práctica no detecta errores que la compilación no detectaría de todos modos. Solo hay un escenario descabellado en el que la anulación de los implementadores realmente hace algo: si implementa una interfaz y la interfaz ELIMINA los métodos, se le notificará en tiempo de compilación que debe eliminar las implementaciones no utilizadas. Tenga en cuenta que si la nueva versión de la interfaz tiene métodos NUEVOS o CAMBIADOS, obviamente obtendrá un error de compilación de todos modos ya que no está implementando las nuevas cosas.

@Override en implementadores de interfaz nunca debería haberse permitido en 1.6, y con eclipse lamentablemente eligiendo insertar automáticamente las anotaciones como comportamiento predeterminado, obtenemos muchos archivos fuente desordenados. Al leer el código 1.6, no puede ver en la anotación @Override si un método realmente anula un método en la superclase o simplemente implementa una interfaz.

Usar @Override cuando realmente anula un método en una superclase está bien.

Es mejor usarlo para todos los métodos destinados a anulación, y Java 6+, todos los métodos destinados a la implementación de una interfaz.

Primero, detecta errores ortográficos como " hashcode()" en lugar de " hashCode()" en tiempo de compilación. Puede ser desconcertante depurar por qué el resultado de su método no parece coincidir con su código cuando la verdadera causa es que su código nunca se invoca.

Además, si una superclase cambia la firma de un método, las anulaciones de la firma anterior pueden quedar "huérfanas" y quedar como código muerto confuso. La @Overrideanotación lo ayudará a identificar a estos huérfanos para que puedan modificarse para que coincidan con la nueva firma.

Si te encuentras anulando métodos (no abstractos) muy a menudo, probablemente quieras echar un vistazo a tu diseño. Es muy útil cuando el compilador no detectaría el error. Por ejemplo, tratar de anular initValue () en ThreadLocal, lo que he hecho.

Usar @Override al implementar métodos de interfaz (función 1.6+) me parece un poco exagerado. Si tiene muchos métodos, algunos de los cuales anulan y otros no, ese probablemente sea un mal diseño nuevamente (y su editor probablemente mostrará cuál es cuál si no lo sabe).

@Override en las interfaces en realidad son útiles, porque recibirá advertencias si cambia la interfaz.

Otra cosa que hace es que al leer el código es más obvio que está cambiando el comportamiento de la clase principal. Que puede ayudar en la depuración.

Además, en el libro de Joshua Block, Effective Java (2nd edition), el ítem 36 brinda más detalles sobre los beneficios de la anotación.

No tiene ningún sentido usar @Override al implementar un método de interfaz. No hay ninguna ventaja en usarlo en ese caso: el compilador ya detectará su error, por lo que es un desorden innecesario.

Cada vez que un método anula otro método, o un método implementa una firma en una interfaz.

La @Overrideanotación le asegura que de hecho anuló algo. Sin la anotación, corre el riesgo de una falta de ortografía o una diferencia en los tipos y números de parámetros.

Lo uso todo el tiempo. Es más información que puedo usar para descubrir rápidamente lo que sucede cuando reviso el código en un año y he olvidado lo que estaba pensando la primera vez.

Lo mejor es usarlo siempre (o hacer que el IDE lo complete por usted)

La utilidad de @Override es detectar cambios en las clases principales que no se han informado en la jerarquía. Sin él, puede cambiar la firma de un método y olvidar alterar sus anulaciones, con @Override, el compilador lo detectará por usted.

Ese tipo de red de seguridad siempre es bueno tener.

Lo uso en todas partes. Sobre el tema del esfuerzo por marcar métodos, dejé que Eclipse lo haga por mí, así que no es un esfuerzo adicional.

Soy religioso con respecto a la refactorización continua ... por lo tanto, usaré cada pequeña cosa para que funcione mejor.

• Usado solo en declaraciones de métodos.
• Indica que la declaración del método anotado anula una declaración en supertipo.

Si se usa de manera consistente, lo protege de una gran clase de errores nefastos.

Use la anotación @Override para evitar estos errores: (Detecte el error en el siguiente código :)

public class Bigram {
    private final char first;
    private final char second;
    public Bigram(char first, char second) {
        this.first  = first;
        this.second = second;
    }
    public boolean equals(Bigram b) {
        return b.first == first && b.second == second;
    }
    public int hashCode() {
        return 31 * first + second;
    }

    public static void main(String[] args) {
        Set<Bigram> s = new HashSet<Bigram>();
        for (int i = 0; i < 10; i++)
            for (char ch = 'a'; ch <= 'z'; ch++)
                s.add(new Bigram(ch, ch));
        System.out.println(s.size());
    }
}

fuente: Java efectivo

Tenga cuidado cuando use Override, porque no puede hacer ingeniería inversa en starUML después; hacer la uml primero.

Parece que la sabiduría aquí está cambiando. Hoy instalé IntelliJ IDEA 9 y noté que su " falta de inspección @Override " ahora capta no solo los métodos abstractos implementados, sino también los métodos de interfaz implementados. En la base de código de mi empleador y en mis propios proyectos, siempre he tenido la costumbre de usar @Override para los métodos abstractos implementados anteriormente. Sin embargo, al repensar el hábito, queda claro el mérito de usar las anotaciones en ambos casos. A pesar de ser más detallado, protege contra la clase base frágil problema de la (no tan grave como los ejemplos relacionados con C ++) donde el nombre del método de interfaz cambia, dejando huérfano al posible método de implementación en una clase derivada.

Por supuesto, este escenario es principalmente una hipérbole; la clase derivada ya no se compilaría, ahora carece de una implementación del método de interfaz renombrado, y hoy probablemente se usaría un Método de cambio de nombre operación de refactorización del para abordar la base de código completa en masa.

Dado que la inspección de IDEA no es configurable para ignorar los métodos de interfaz implementados, hoy cambiaré tanto mi hábito como los criterios de revisión de código de mi equipo.

La anotación @Override se usa para ayudar a verificar si el desarrollador debe anular el método correcto en la clase o interfaz principal. Cuando el nombre de los métodos de super cambia, el compilador puede notificar ese caso, que es solo para mantener la coherencia con el super y la subclase.

Por cierto, si no anunciamos la anotación @Override en la subclase, pero anulamos algunos métodos de la super, entonces la función puede funcionar como esa con la @Override. Pero este método no puede notificar al desarrollador cuando se cambió el método del super. ¿Porque no conocía el propósito del desarrollador: anular el método de super o definir un nuevo método?

Entonces, cuando queremos anular ese método para hacer uso del Polimorfismo, es mejor agregar @Override sobre el método.

Lo uso todo lo que puedo para identificar cuándo se anula un método. Si observa el lenguaje de programación Scala, también tienen una palabra clave de anulación. Me parece útil

Le permite (bueno, el compilador) detectar cuando ha usado la ortografía incorrecta en un nombre de método que está anulando.

La anulación de anulación se utiliza para aprovechar el compilador, para verificar si realmente está anulando un método de la clase principal. Se utiliza para notificar si comete algún error, como error de escribir mal el nombre de un método, error de no coincidir correctamente los parámetros

Creo que es mejor codificar el @override siempre que esté permitido. Ayuda para la codificación. sin embargo, debe tenerse en cuenta que para ecipse Helios, ya sea sdk 5 o 6, se permite la anotación @override para los métodos de interfaz implementados. En cuanto a Galileo, ya sea 5 o 6, no se permite la anulación de anulación.

Las anotaciones proporcionan metadatos sobre el código al Compilador y la anotación @Override se usa en caso de herencia cuando anulamos cualquier método de clase base. Simplemente le dice al compilador que está anulando el método. Puede evitar algunos tipos de errores comunes que podemos hacer, como no seguir la firma adecuada del método o escribir mal en el nombre del método, etc. Por lo tanto, es una buena práctica utilizar la anotación @Override.

Para mí, @Override me asegura que tengo la firma del método correcta. Si pongo la anotación y el método no está escrito correctamente, entonces el compilador se queja dejándome saber que algo está mal.

Simple: cuando desee anular un método presente en su superclase, use la @Overrideanotación para hacer una anulación correcta. El compilador le avisará si no lo anula correctamente.