Uso de la palabra clave override en implementaciones de métodos abstractos

Question

¿Es una buena práctica utilizar la palabra clave override al implementar métodos abstractos definidos en rasgos?

trait Tooth { 
    def ache(): Unit 
} 

class Molar extends Tooth { 
    override def ache(): Unit = {} 
} 

En el ejemplo anterior, entiendo que la palabra clave de anulación es opcional; pero es aconsejable? ¿De qué lado de la concisión versus compromiso de seguridad debo caer?

Answer 1

override hace una cosa por usted allí: al eliminar Tooth.ache pero no sus implementaciones más adelante, obtendrá errores de compilación. En particular, esto obliga a las implementaciones de Tooth (escritas por usted o por otros) a estar "cerca" de Tooth en un cierto sentido, a saber, que los métodos obsoletos desaparecen (o al menos son reconsiderados).

Esto puede o no puede ser deseado.

Answer 2

Personalmente, cuando veo

override def whatever() 

el primero que pienso es: "Me pregunto cómo se suponía que esto comporte antes?"

Dado que este es un pensamiento inútil si se trataba de un método abstracto, me resulta más seguro y dejarlo así.

Answer 3

Siempre lo uso, para indicar el miembro que se declaró en las súper clases, incluso si es abstracto.

Answer 4

Normalmente no uso la anulación al implementar un método abstracto. No está mal, pero es redundante, y prefiero mantener mi código lo más corto posible manteniendo la claridad. Pero me doy cuenta de que no es un caso claro.