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

https://stackoverflow.com/questions/94361

01-07-2019
|

Question

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

Il semble exagéré de marquer chaque méthode surchargée avec l'annotation @Override . Certaines situations de programmation nécessitent-elles l’utilisation de @Override et d’autres qui ne doivent jamais utiliser @Override ?

La solution

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

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

Autres conseils

Je pense qu'il est très utile de rappeler à la compilation que l'intention de la méthode est de remplacer une méthode parente. Par exemple:

protected boolean displaySensitiveInformation() {
  return false;
}

Vous verrez souvent quelque chose comme la méthode ci-dessus qui remplace une méthode dans 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 parent en

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

Cette modification ne causera aucune erreur de temps de compilation ni aucun avertissement, mais modifiera complètement le comportement souhaité de la sous-classe.

Pour répondre à votre question, vous devez utiliser l'annotation @Override si l'absence d'une méthode avec la même signature dans une super-classe est révélatrice d'un bogue.

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 de surmenage lorsque vous codez. Taper @override ne vous coûte rien, mais les économies peuvent être énormes si vous mal orthographiez le nom d'une méthode ou si la signature est légèrement fausse.

Pensez-y de la manière suivante: pendant le temps où vous avez navigué ici et tapé ce message, vous avez utilisé plus de temps que nécessaire à taper @override pour le reste de votre vie; mais une erreur qu’elle évite peut vous faire économiser des heures.

Java fait tout ce qui est en son pouvoir pour s’assurer que vous n’avez commis aucune erreur au moment de l’édition / compilation, c’est un moyen pratiquement gratuit de résoudre toute une catégorie d’erreurs qui ne peuvent être prévenues autrement que par des tests complets. .

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

Un autre effet intéressant est que si vous ne fournissez pas l'annotation, elle vous avertira lors de la compilation que vous surchargez accidentellement une méthode parente - ce qui pourrait être significatif si vous n'aviez pas l'intention de le faire.

J'utilise toujours la balise. C’est un simple drapeau de compilation qui permet de détecter les petites erreurs que je pourrais commettre.

Il interceptera des éléments tels que tostring () au lieu de toString ()

Les petites choses aident dans les grands projets.

L'utilisation de l'annotation @Override agit comme une sauvegarde lors de la compilation contre une erreur de programmation courante. Une erreur de compilation se produira si vous avez l'annotation sur une méthode et que vous ne remplacez pas réellement la méthode superclass.

Le cas le plus courant où cela est utile est lorsque vous modifiez une méthode dans la classe de base pour avoir une liste de paramètres différente. Une méthode dans une sous-classe qui remplaçait la méthode superclass ne le fera plus en raison de la signature de méthode modifiée. Cela peut parfois provoquer un comportement étrange et inattendu, en particulier lorsqu'il s'agit de structures d'héritage complexes. L'annotation @Override protège contre cela.

Pour tirer parti de la vérification du compilateur, vous devez toujours utiliser l'annotation Remplacer. Mais n'oubliez pas que Java Compiler 1.5 n'autorisera pas cette annotation lors de la substitution des méthodes d'interface. Vous pouvez simplement l'utiliser pour redéfinir les méthodes de classe (abstraites ou non).

Certains IDE, comme Eclipse, même configurés avec Java 1.6 ou supérieur, maintiennent la conformité avec Java 1.5 et ne permettent pas l’utilisation de @override comme décrit ci-dessus. Pour éviter ce problème, vous devez accéder à: Propriétés du projet - > Compilateur Java - > Cochez la case "Activer les paramètres spécifiques au projet" & # 8221; - > Choisissez le niveau de conformité du compilateur & # 8221; = 6.0 ou supérieur.

J'aime utiliser cette annotation à chaque fois que je redéfinis une méthode indépendamment, si la base est une interface ou une classe.

Cela vous aide à éviter certaines erreurs typiques, comme lorsque vous pensez que vous substituez un gestionnaire d'événements et que rien ne se passe. Imaginez que vous souhaitiez ajouter un écouteur d'événement à un composant de l'interface utilisateur:

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

Le code ci-dessus est compilé et exécuté, mais si vous déplacez la souris à l'intérieur d'un composant UIComponent, l'option & # 8220; faire quelque chose & # 8221; code sera noté comme étant exécuté, car vous ne substituez pas la méthode de base mouseEntered (MouseEvent ev) . Vous venez de créer une nouvelle méthode sans paramètre mouseEntered () . Au lieu de ce code, si vous avez utilisé l'annotation @Override , vous avez constaté une erreur de compilation et vous ne perdez pas de temps à vous demander pourquoi votre gestionnaire d'événements ne s'exécutait pas.

@Override sur la mise en œuvre de l'interface est incohérent, car il n'existe pas de possibilité de "substitution d'une interface". en java.

@Override sur la mise en œuvre de l'interface est inutile car, dans la pratique, il ne détecte aucun bogue que la compilation ne détecterait pas de toute façon. Il n'y a qu'un seul scénario, très recherché, où le remplacement par les implémenteurs agit réellement: si vous implémentez une interface et les méthodes REMOVES de l'interface, vous serez averti au moment de la compilation que vous devez supprimer les implémentations inutilisées. Notez que si la nouvelle version de l'interface comporte des méthodes NEW ou CHANGED, vous obtiendrez évidemment une erreur de compilation de toute façon, car vous n'implémentez pas les nouveaux éléments.

@Override sur les implémenteurs d'interface n'aurait jamais dû être autorisé dans 1.6, et avec eclipse choisissant malheureusement d'insérer automatiquement les annotations comme comportement par défaut, nous obtenons beaucoup de fichiers sources encombrés. Lors de la lecture du code 1.6, vous ne pouvez pas voir dans l'annotation @Override si une méthode remplace en réalité une méthode de la superclasse ou implémente simplement une interface.

Utiliser @Override pour redéfinir une méthode dans une super-classe est acceptable.

Il est préférable de l’utiliser pour chaque méthode conçue comme une substitution, et Java 6+, chaque méthode destinée à la mise en oeuvre d’une interface.

Tout d’abord, il détecte les fautes d’orthographe telles que " hashcode () " au lieu de " hashCode () " au moment de la compilation. Il peut être déroutant de déboguer pourquoi le résultat de votre méthode ne semble pas correspondre à votre code alors que la cause réelle en est que votre code n'est jamais appelé.

En outre, si une super-classe modifie une signature de méthode, les remplacements de la signature plus ancienne peuvent être "orphelins", laissés comme un code mort source de confusion. L'annotation @Override vous aidera à identifier ces orphelins afin qu'ils puissent être modifiés pour correspondre à la nouvelle signature.

Si vous vous retrouvez souvent en train de surcharger des méthodes (non abstraites), vous voudrez probablement jeter un coup d'œil à votre conception. Il est très utile que le compilateur n’attrape pas l’erreur autrement. Par exemple, essayer de remplacer initValue () dans ThreadLocal, ce que j’ai fait.

Utiliser @Override lors de l’implémentation de méthodes d’interface (fonctionnalité 1.6+) semble un peu excessif pour moi. Si vous avez des tas de méthodes dont certaines remplacent et d’autres pas, cette mauvaise conception sera probablement à nouveau mauvaise (et votre éditeur vous montrera probablement ce qui est si vous ne le savez pas).

@Override sur les interfaces est réellement utile, car vous obtiendrez des avertissements si vous modifiez l'interface.

Cela a également pour effet de rendre plus évident, lors de la lecture du code, le fait de modifier le comportement de la classe parente. Than peut aider au débogage.

En outre, dans le livre de Joshua Block, Effective Java (2e édition), le point 36 donne plus de détails sur les avantages de l'annotation.

Il n’a absolument aucun sens d’utiliser @Override lors de l’implémentation d’une méthode d’interface. Il n'y a aucun avantage à l'utiliser dans ce cas - le compilateur aura déjà compris votre erreur, c'est donc un fouillis inutile.

Chaque fois qu'une méthode remplace une autre méthode ou qu'une méthode implémente une signature dans une interface.

L'annotation @Override vous assure que vous avez en réalité annulé quelque chose. Sans l'annotation, vous risquez une faute d'orthographe ou une différence dans les types et le nombre de paramètres.

Je l'utilise à chaque fois. C’est plus d’informations que je peux utiliser pour comprendre rapidement ce qui se passe lorsque je revisite le code au cours d’une année et que j’ai oublié ce que je pensais la première fois.

La meilleure pratique est de toujours l'utiliser (ou de laisser l'IDE les remplir à votre place)

L’utilité de @Override est de détecter les changements dans les classes parentes qui n’ont pas été signalés dans la hiérarchie. Sans cela, vous pouvez modifier une signature de méthode et oublier de modifier ses substitutions. Avec @Override, le compilateur la détectera pour vous.

Ce genre de filet de sécurité est toujours utile.

Je l'utilise partout. En ce qui concerne l’effort pour les méthodes de marquage, je laisse Eclipse le faire pour moi, donc ce n’est pas un effort supplémentaire.

Je suis religieux en ce qui concerne la refactorisation continue .... je vais donc utiliser chaque petite chose pour que cela se passe mieux.

Utilisé uniquement dans les déclarations de méthode.
Indique que la méthode annotée déclaration remplace une déclaration en supertype.

S'il est utilisé de manière cohérente, il vous protège contre une grande classe de bogues néfastes.

Utilisez les annotations @Override pour éviter ces bugs: (Repérez le bogue dans le code suivant:)

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());
    }
}

source: Java efficace

Faites attention lorsque vous utilisez Override, car vous ne pourrez pas faire d'ingénierie inverse dans starUML par la suite. faire le premier uml.

Il semble que la sagesse change ici. Aujourd'hui, j'ai installé IntelliJ IDEA 9 et constaté que son " manquant @Override inspection " capture désormais non seulement les méthodes abstraites implémentées, mais également les méthodes d'interface implémentées. Dans la base de code de mon employeur et dans mes propres projets, j'ai depuis longtemps l'habitude d'utiliser uniquement @Override pour les méthodes abstraites précédemment implémentées. Cependant, en repensant cette habitude, l'intérêt d'utiliser les annotations dans les deux cas devient évident. Bien qu’il soit plus détaillé, il protège contre le problème de la classe de base fragile (pas aussi grave que les exemples liés à C ++) dans lequel le nom de la méthode d’interface change, rendant ainsi orpheline la méthode en cours d’implémentation dans une classe dérivée.

Bien sûr, ce scénario est principalement une hyperbole; la classe dérivée ne compilerait plus, il manquait maintenant d'implémentation de la méthode d'interface renommée et aujourd'hui, on utiliserait probablement une opération de refactoring Rename Method pour traiter en masse la base de code entière.

Etant donné que l'inspection d'IDEA n'est pas configurable pour ignorer les méthodes d'interface implémentées, je vais aujourd'hui changer à la fois mes habitudes et les critères de révision du code de mon équipe.

L'annotation @Override permet de vérifier si le développeur doit redéfinir la méthode appropriée dans la classe ou l'interface parente. Lorsque le nom des méthodes de super change, le compilateur peut notifier ce cas, ce qui sert uniquement à maintenir la cohérence avec le super et la sous-classe.

BTW, si nous n’annonçons pas l’annotation @Override dans la sous-classe, mais que nous substituons certaines méthodes de la classe super, la fonction peut alors fonctionner comme celle-ci avec @Override. Mais cette méthode ne peut pas informer le développeur lorsque la méthode du super a été modifiée. Parce qu'il ne connaissait pas l'objectif du développeur - outrepasser la méthode de super ou définir une nouvelle méthode?

Ainsi, lorsque nous souhaitons redéfinir cette méthode pour utiliser le polymorphisme, il est préférable d’ajouter @Override au-dessus de la méthode.

Je l'utilise autant que possible pour identifier le moment où une méthode est redéfinie. Si vous regardez le langage de programmation Scala, ils ont aussi un mot clé prioritaire. Je trouve cela utile.

Cela vous permet (ainsi au compilateur) d’attraper lorsque vous avez mal orthographié le nom de la méthode que vous substituez.

L'annotation de substitution permet de tirer parti du compilateur pour vérifier si vous substituez réellement une méthode à la classe parente. Il est utilisé pour notifier si vous faites une erreur telle qu'une erreur de mal orthographier un nom de méthode, une erreur de ne pas correspondre correctement aux paramètres

Je pense qu'il est préférable de coder le @override chaque fois que cela est autorisé. cela aide pour le codage. toutefois, pour ecipse Helios, soit sdk 5 ou 6, l'annotation @override des méthodes d'interface implémentées est autorisée. comme pour Galileo, 5 ou 6, l’annotation @override n’est pas autorisée.

Les annotations fournissent des métadonnées sur le code au compilateur et l'annotation @Override est utilisée en cas d'héritage lorsque nous substituons une méthode de la classe de base. Cela indique simplement au compilateur que vous substituez la méthode. Cela peut éviter certaines erreurs courantes que nous pouvons commettre, comme ne pas suivre la signature correcte de la méthode ou mal orthographier le nom de la méthode, etc. C'est donc une bonne pratique d'utiliser l'annotation @Override.

Pour moi, @Override m'assure que la signature de la méthode est correcte. Si je mets dans l'annotation et que la méthode n'est pas orthographiée correctement, le compilateur se plaint de me faire savoir que quelque chose ne va pas.

Simple & # 8211; lorsque vous souhaitez remplacer une méthode présente dans votre super-classe, utilisez l'annotation @Override pour effectuer un remplacement correct. Le compilateur vous avertira si vous ne le remplacez pas correctement.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow