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

override netbeans

Question

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

Parece que sería excesivo marcar cada método anulado con la anotación @Override . ¿Hay ciertas situaciones de programación que requieren el uso de @Override y otras que nunca deben usar el @Override ?

Answer 1

Úselo cada vez que invalide un método para obtener dos beneficios. Hágalo de modo que pueda aprovechar la comprobación del compilador para asegurarse de que realmente está anulando un método cuando cree que lo está. De esta manera, si comete un error común de escribir incorrectamente un nombre de método o no coincidir correctamente con los parámetros, se le advertirá que su método no se anula realmente como cree que lo hace. 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 cuando un método implementa una interfaz para los mismos beneficios. Creo que sería mejor tener una anotación separada (como @Implements ), pero es mejor que nada.

Answer 2

@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 muy poco probable 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 el momento de la 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 cosas nuevas.

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

Usar @Override cuando en realidad está anulando un método en una superclase está bien.

Answer 3

@Override en las interfaces realmente es útil, ya que recibirá advertencias si cambia la interfaz.

Answer 4

Aquí hay muchas respuestas buenas, así que permítame ofrecerle otra manera de verlo ...

No hay exceso cuando estás codificando. No le cuesta nada escribir @ override, pero los ahorros pueden ser inmensos si se escribe mal el nombre de un método o si la firma es incorrecta.

Piénselo de esta manera: en el tiempo que navegó aquí y escribió esta publicación, usó mucho más tiempo del que pasaría escribiendo @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 cometió 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 integrales.

¿Podría idear un mejor mecanismo en Java para garantizar que cuando el usuario tenía la intención de anular un método, realmente lo hizo?

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

Answer 5

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

La anotación @Override le asegura que, de hecho, anuló algo. Sin la anotación, se arriesga a escribir mal o una diferencia en los tipos de parámetros y el número.

Answer 6

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 para

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

Este cambio no causará ningún error de tiempo de compilación o advertencias, pero cambia completamente el comportamiento deseado 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 indicativa de un error.

Answer 7

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

Answer 8

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

El caso más común donde 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 superclase ya no lo hará debido a la firma del método cambiado. Esto a veces puede causar un comportamiento extraño e inesperado, especialmente cuando se trata de estructuras complejas de herencia. La anotación de @Override protege contra esto.

Answer 9

Es mejor usarlo para todos los métodos destinados a anularse, y Java 6+, todos los métodos para implementar como interfaz.

Primero, detecta faltas de ortografía 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 causa real es que nunca se invoca su código.

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

Answer 10

La anotación @Override se utiliza para ayudar a verificar si el desarrollador debe anular el método correcto en la clase o interfaz principal. Cuando cambia el nombre de los métodos de super, 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 @Averride en la subclase, pero sí anulamos algunos métodos de super, entonces la función puede funcionar como esa con @Override. Pero este método no puede notificar al desarrollador cuando se cambió el método de los súper. ¿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, tenemos que agregar @Override sobre el método.

Answer 11

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

Answer 12

Las anotaciones proporcionan metadatos sobre el código para el compilador y la anotación @Override se utiliza en caso de herencia cuando estamos anulando 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 correcta del método o escribir mal el nombre del método, etc. Por lo tanto, es una buena práctica usar la anotación Override.

Answer 13

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

Answer 14

Lo mejor es usarlo siempre (o hacer que el IDE los llene por usted)

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

Ese tipo de red de seguridad siempre es bueno tener.

Answer 15

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

Soy religioso sobre la refactorización continua ... así que usaré cada pequeña cosa para que sea más fácil.

Answer 16

Lo uso tanto como puedo para identificar cuando un método se está anulando. Si nos fijamos en el lenguaje de programación Scala, también tienen una palabra clave de anulación. Me parece útil.

Answer 17

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

Answer 18

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

Answer 19

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

Además, en el libro Effective Java (segunda edición) de Joshua Block, el artículo 36 brinda más detalles sobre los beneficios de la anotación.

Answer 20

Para aprovechar las ventajas de la comprobación del compilador, siempre debe utilizar Anotar anotació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 (resumen o no).

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

Me gusta usar esta anotación cada vez que sobrescribo 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 suceda nada. Imagina que deseas 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 ejecuta, pero si mueve el mouse dentro de algún UIComponent, el código de "hacer algo" anotará que se ejecuta, porque en realidad no está anulando el método base mouseEntered(MouseEvent ev) . Simplemente crea un nuevo método mouseEntered() parámetros mouseEntered() . En lugar de ese código, si ha utilizado la anotación @Override , ha visto un error de compilación y no ha estado perdiendo el tiempo pensando por qué no se estaba ejecutando el controlador de eventos.

Answer 21

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

Answer 22

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

Por supuesto, este escenario es en su mayoría hipérbole; la clase derivada ya no se compilaría, ahora carece de una implementación del método de interfaz renombrado, y hoy en día uno probablemente usaría una operación de refactorización del método Renombrar para abordar la base del código completo en masa.

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

Answer 23

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

Utilizar @Override al implementar métodos de interfaz (1.6+ característica) me parece un poco excesivo. Si tiene montones de métodos, algunos de los cuales anulan y otros no, ese nuevo diseño probablemente no sea bueno (y su editor probablemente mostrará cuál es cuál si no lo sabe).

Answer 24

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

Answer 25

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

Answer 26

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

tostring() cosas como tostring() lugar de toString()

Las pequeñas cosas ayudan en grandes proyectos.

Answer 27

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

Si se usa constantemente, lo protege de una gran clase de bichos nefarios.

Use la anotación @Override para evitar estos errores: (Localice 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 efectiva