Quand utilisez-vous l'annotation @Override de Java et pourquoi ?

Question

Quelles sont les meilleures pratiques pour utiliser l'interface de Java @Override annotation et pourquoi ?

Il semble qu'il serait exagéré de marquer chaque méthode surchargée avec la balise @Override annotation. Existe-t-il certaines situations de programmation qui nécessitent l'utilisation de l'annotation @Override et d'autres qui ne devraient jamais utiliser le @Override ?

Answer 1

Utilisez-le chaque fois que vous remplacez une méthode pour deux avantages. Faites-le afin de profiter de la vérification du compilateur pour vous assurer que vous surchargez réellement une méthode lorsque vous pensez le faire. Ainsi, si vous commettez l'erreur courante de mal orthographier le nom d'une méthode ou de ne pas faire correspondre correctement les paramètres, vous serez averti que votre méthode n'est pas réellement prioritaire comme vous le pensez. Deuxièmement, cela rend votre code plus facile à comprendre car il est plus évident de savoir quand les méthodes sont remplacées.

De plus, en Java 1.6, vous pouvez l'utiliser pour indiquer quand une méthode implémente une interface pour les mêmes avantages. Je pense qu'il serait mieux d'avoir une annotation séparée (comme @Implements ), mais c'est mieux que rien.

Answer 2

Je pense que c'est surtout utile pour rappeler au moment de la compilation que l'intention de la méthode est de surcharger une méthode parente. Par exemple :

protected boolean displaySensitiveInformation() {
  return false;
}

Vous verrez souvent quelque chose comme la méthode ci-dessus qui surcharge une méthode de la classe de base. Il s'agit d'un détail d'implémentation important de cette classe : nous ne voulons pas que des informations sensibles soient affichées.

Supposons que cette méthode soit modifiée dans la classe parente en

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

Cette modification ne provoquera pas d'erreurs ou d'avertissements au moment de la compilation, mais elle modifie complètement le comportement prévu de la sous-classe.

Pour répondre à votre question : vous devriez utiliser l'annotation @Override si l'absence d'une méthode ayant la même signature dans une superclasse est le signe d'un bug.

Answer 3

Il y a beaucoup de bonnes réponses ici, alors laissez-moi vous proposer une autre façon de voir les choses...

Il n'y a pas d'excès quand on codifie. Il ne vous coûte rien de taper @override, mais les économies peuvent être immenses si vous avez mal orthographié le nom d'une méthode ou si vous vous êtes légèrement trompé dans la signature.

Pensez-y de cette façon : Pendant le temps que vous avez passé à naviguer ici et à taper cet article, vous avez utilisé plus de temps que vous n'en passerez à taper @override pour le reste de votre vie ; mais une erreur qu'elle évite peut vous faire gagner des heures.

Java fait tout ce qu'il peut pour s'assurer que vous n'avez pas fait d'erreurs au moment de l'édition/de la compilation, c'est un moyen pratiquement gratuit de résoudre toute une catégorie d'erreurs qui ne peuvent être évitées d'aucune autre manière en dehors de tests complets.

Pourriez-vous proposer un meilleur mécanisme en Java pour garantir que lorsque l'utilisateur a l'intention de remplacer une méthode, il le fait réellement ?

Un autre effet intéressant est que si vous ne fournissez pas l'annotation, vous serez averti au moment de la compilation que vous avez accidentellement remplacé une méthode parente, ce qui pourrait être important si vous n'aviez pas l'intention de le faire.

Answer 4

J'utilise toujours l'étiquette. Il s'agit d'un simple indicateur de compilation qui permet de détecter les petites erreurs que je pourrais commettre.

Il attrapera des choses comme tostring() au lieu de toString()

Les petites choses aident dans les grands projets.

Answer 5

Utilisation de la @Override agit comme une protection au moment de la compilation contre une erreur de programmation courante. Une erreur de compilation sera générée si l'annotation est appliquée à une méthode qui ne surcharge pas réellement la méthode de la superclasse.

Le cas le plus courant où cela est utile est lorsque vous modifiez une méthode de la classe de base pour avoir une liste de paramètres différente. Une méthode dans une sous-classe qui surchargeait la méthode de la super-classe ne le fera plus en raison de la modification de la signature de la méthode. Cela peut parfois provoquer un comportement étrange et inattendu, surtout lorsqu'il s'agit de structures d'héritage complexes. Le site @Override permet de s'en prémunir.