usa - what does override mean in java




¿Cuándo usas la anotación @Override de Java y por qué? (18)

Ú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.

¿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 ?


@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.


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.


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.


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.


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.


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.


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


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


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.


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.


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.


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.


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.


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.


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).


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


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.





annotations