CodeGym /Blog Java /Random-FR /Annotations. Partie 1 - un peu ennuyeux
John Squirrels
Niveau 41
San Francisco

Annotations. Partie 1 - un peu ennuyeux

Publié dans le groupe Random-FR
Partie 1. J'ai écrit très brièvement sur les annotations de type SOURCE et CLASS. Cela vaut la peine d'être lu, afin d'éviter de se perdre dans la deuxième partie et d'élargir un peu votre "malentendu" =) Promis, il y aura certainement au moins un mot que vous connaissez ! Annotations.  Partie 1 - un peu ennuyeux - 1 La première fois que j'ai vu des annotations dans les tâches ici, je n'y ai pas prêté beaucoup d'attention. Il y a @Override ici et là, mais IDEA ajoute cela, alors j'ai pensé qu'il devait en être ainsi. Au fil du temps, j'ai réalisé que tout est beaucoup plus profond. Au fur et à mesure que vous étudiez, les annotations peuvent sembler quelque peu inutiles mais nécessaires. Vous ne savez pas pourquoi ils existent ou ce qu'ils font. Vous avez lu quelques articles qui disaient : "c'est tellement bien que nous ayons des annotations maintenant, tout est devenu si simple". Mais je ne savais pas comment c'était avant, et je ne comprenais pas que les choses sont plus faciles maintenant. Maintenant je sais et je veux partager un peu. Il existe 3 types d'annotations (RetentionPolicy) :
  • SOURCE — Annotations pour le compilateur
  • CLASS — Les informations de l'annotation seront écrites en bytecode mais ne seront pas disponibles au moment de l'exécution. Ils disent que la bibliothèque standard contient de nombreuses annotations de ce type, qui sont maintenant conservées pour une compatibilité descendante. Ceci est utilisé pour des tâches très spécifiques.
  • Questions et réponses sur StackOverflow
  • RUNTIME — Ces annotations sont les plus populaires. Ils sont utilisés pendant l'exécution du code.
L'introduction a occupé une partie de l'article, je vais donc écrire ici sur les annotations SOURCE et CLASS. Ce sont les annotations que j'ai pu trouver (grâce à la tâche 3607). Je n'aborderai pas les annotations d'exécution — elles sont trop nombreuses et ne font pas l'objet de cet article. SOURCE:
  • java/lang/annotation/Native.class ;
  • java/lang/SuppressWarnings.class
  • javax/annotation/Generated.class
  • java/lang/Override.class
CLASSE: Je ne sais pas pourquoi les annotations CLASS sont nécessaires. La documentation des annotations existantes est introuvable, donc je pense que vous pouvez simplement laisser ce bagage derrière vous. Mais si vous le trouvez, merci de le partager. Annotations SOURCE :
  1. Natif — Une variable avec cette annotation peut faire référence au code natif ;
  2. SuppressWarnings — Cette annotation supprime divers avertissements du compilateur ;
  3. Généré — Cette annotation marque le code source qui a été généré ;
  4. Override — Cette annotation vérifie les remplacements de méthode.
Pour plus d'informations:

@Indigène

Native - je n'ai jamais vu cela et je ne l'ai jamais utilisé. Je pense que c'est une annotation plutôt rare, car elle est utilisée lorsque vous devez exécuter du code dans un autre langage "natif". J'ai essayé et je n'ai pas réussi à en trouver une mention claire.

@Supprimer les avertissements

SuppressWarnings — Cette annotation est souvent utilisée comme ceci : @SuppressWarnings("unchecked"). Il est utilisé pour supprimer les avertissements dont vous avez déjà connaissance. L'exemple précédent supprime les avertissements concernant les conversions de type non contrôlées. Encore une fois, c'est la seule utilisation que j'ai rencontrée.

@Généré

Généré - Je rencontre actuellement cette annotation en raison d'une affectation dans laquelle je dois générer des classes à partir de fichiers XSD. Ces 3 annotations sont assez spécifiques et ne vous intéressent probablement pas pour le moment. Je vais décrire le dernier.

@Passer outre

Remplacer - Vous l'utilisez constamment et il fait quelque chose de très utile. Lors de la redéfinition d'une méthode, il est facile de faire une erreur sans l'aide d'IDEA. Qu'il s'agisse de fautes de frappe ou de simples erreurs, des erreurs se produisent. Cette annotation garantira que la méthode de la classe parent correspond à notre méthode (annotée). Cela garantit que la méthode sera remplacée plutôt qu'ajoutée. Lors de la refactorisation du code, la méthode parent peut être supprimée ou modifiée. Encore une fois, cette annotation indiquera une erreur. Sans cela, notre méthode serait simplement ajoutée. Ennuyeux? Je dirais oui. Il n'y a pas grand-chose d'utile à tirer de cet article. Presque tout (90%) ici décrit quelque chose que vous n'utiliserez jamais ou très rarement. Les 10% restants saluent et décrivent l'annotation @Override, qui à première vue est inutile. Cela dit, je pense que la deuxième partie de l'article sera plus intéressante. Il y aura des discussions sur les annotations RUNTIME - elles interagissent avec le code pendant l'exécution et font de la magie noire. Annotations. Partie 2. Lombok
Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION