Pourquoi marquer les variables locales et les paramètres de méthode avec "final" & # 8221; en Java? [fermé]

StackOverflow https://stackoverflow.com/questions/316352

  •  11-07-2019
  •  | 
  •  

Question

En Java, vous pouvez qualifier les variables locales et les paramètres de méthode à l'aide du mot clé final.

public static void foo(final int x) {
  final String qwerty = "bar"; 
}

Cela empêcherait de réaffecter x et qwerty dans le corps de la méthode.

Cette pratique pousse votre code dans le sens de l’immuabilité, ce qui est généralement considéré comme un plus. Mais, il a également tendance à encombrer le code avec "final". se présenter partout. Quelle est votre opinion sur le mot-clé final pour les variables locales et les paramètres de méthode en Java?

Était-ce utile?

La solution

Vous devriez essayer de faire cela chaque fois que cela vous conviendra. En plus de servir à vous avertir lorsque vous "accidentellement" essayez de modifier une valeur, elle fournit au compilateur des informations pouvant conduire à une meilleure optimisation du fichier de classe. C’est l’un des points du livre "Hardcore Java". par Robert Simmons, Jr. En fait, le livre consacre tout son deuxième chapitre à l'utilisation de final pour promouvoir les optimisations et éviter les erreurs de logique. Des outils d’analyse statique, tels que PMD et le SA intégré d’Eclipse, signalent ce type de cas pour cette raison.

Autres conseils

Mon opinion personnelle est que c'est une perte de temps. Je crois que l'encombrement visuel et la verbosité ajoutée n'en valent pas la peine.

Je n'ai jamais été dans une situation où j'ai réaffecté (rappelez-vous, cela ne rend pas les objets immuables, cela signifie simplement que vous ne pouvez pas réaffecter une autre référence à une variable) une variable en erreur.

Mais, bien sûr, ce sont toutes les préférences personnelles ;-)

La définition finale d’un paramètre garantit que la valeur utilisée à n’importe quel emplacement de la méthode fait référence à la valeur transmise. Sinon, vous devez analyser mentalement tout le code situé au-dessus d’un emplacement donné pour connaître la valeur du paramètre à cet endroit.

Par conséquent, ne pas utiliser final rend votre code moins lisible et plus difficilement maintenable, tout seul:)

Les variables locales finales dépendent de l'intention et sont moins importantes à mes yeux. Cela dépend de ce qui se passe.

Dans le cas des variables locales, j’ai tendance à éviter cela. Cela crée un encombrement visuel et est généralement inutile: une fonction doit être suffisamment courte ou se concentrer sur un seul impact pour vous permettre de voir rapidement que vous modifiez quelque chose qui ne devrait pas l'être.

Dans le cas des nombres magiques, je les placerais comme un champ privé constant de toute façon plutôt que dans le code.

Je n'utilise final que dans les cas où cela est nécessaire (par exemple, transmettre des valeurs à des classes anonymes).

En raison de la nature (parfois occasionnelle) déroutante des " références par Java " comportement Je suis absolument d'accord avec la finalisation du paramètre var.

Finaliser les variables locales semble un peu excessif à l’OMI.

Oui, faites-le.

C'est une question de lisibilité. Il est plus facile de raisonner sur les états possibles du programme lorsque vous savez que les variables sont attribuées une et une seule fois.

Une alternative décente consiste à activer l'avertissement IDE lorsqu'un paramètre est attribué ou lorsqu'une variable (autre qu'une variable de boucle) est affectée plusieurs fois.

final a trois bonnes raisons:

  • les variables d'instance définies par le constructeur ne deviennent immuables
  • les méthodes à ne pas remplacer deviennent finales, utilisez ceci avec des raisons réelles, pas par défaut
  • les variables ou paramètres locaux à utiliser dans des classes anonymes d'une méthode doivent être finaux

Comme les méthodes, les variables et paramètres locaux ne doivent pas nécessairement être déclarés finaux. Comme d'autres l'ont déjà dit, le code devient moins lisible avec très peu d'effort pour l'optimisation des performances du compilateur, ce n'est pas une raison valable pour la plupart des fragments de code.

Bien que cela crée un peu de fouillis, il vaut la peine de mettre final . Ides, par exemple, eclipse peut automatiquement mettre le final si vous le configurez pour le faire.

La création de variables locales et de paramètres de méthode final est essentielle si vous souhaitez passer ces paramètres dans des classes anonymes - comme pour instancier un Thread anonyme et pour accéder à ces paramètres dans le corps de la commande run (). méthode.

À part cela, je ne suis pas sûr des avantages en termes de performances avec de meilleures performances grâce à l’optimisation du compilateur. C’est à l’implémentation spécifique du compilateur de décider s’il veut l’optimiser ou non ...

Il sera bon de connaître les statistiques de performance obtenues avec final ...

.

Pourquoi voudriez-vous? Vous avez écrit la méthode afin que quiconque la modifie puisse toujours supprimer le mot-clé final de qwerty et le réaffecter. En ce qui concerne la signature de la méthode, le même raisonnement, bien que je ne sois pas sûr de ce que cela ferait pour les sous-classes de votre classe ... ils peuvent hériter du paramètre final et même s'ils surchargent la méthode, ne pas être en mesure de dé-finaliser x. Essayez-le et découvrez si cela fonctionnerait.

Le seul avantage réel, donc, est que vous rendiez le paramètre immuable et qu’il se répercute sur les enfants. Sinon, vous encombrez votre code sans raison particulière. Si cela ne force personne à suivre vos règles, il est préférable de laisser un bon commentaire car vous ne devriez pas modifier ce paramètre ou cette variable au lieu de donner le modificateur final.

Modifier

En réponse à un commentaire, j'ajouterai que si vous rencontrez des problèmes de performances, le fait de rendre vos variables et paramètres locaux finaux peut permettre au compilateur d'optimiser votre code. Cependant, du point de vue de l’immuabilité de votre code, je maintiens ma déclaration initiale.

Je laisse Eclipse le faire pour moi lorsqu'ils sont utilisés dans une classe anonyme, ce qui est en augmentation du fait de mon utilisation de l'API Google Collection.

Nous le faisons ici pour les variables locales si nous pensons qu'elles ne seront pas réaffectées ou ne devraient pas l'être.

Les paramètres ne sont pas définitifs car nous avons un Checkstyle-Check qui vérifie la réaffectation des paramètres. Bien entendu, personne ne voudrait jamais réaffecter une variable de paramètre.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top