Avec le modificateur « final » chaque fois qu’il y a lieu en java

Question

En Java, il y a une pratique de déclarer chaque variable (locale ou classe), paramètre final si ils sont vraiment. Bien que cela rend le code beaucoup plus prolixe, cela aide à lecture facile/saisir du code et empêche également les erreurs que l’intention est clairement indiquée.

Quelles sont vos pensées sur ce et ce qui vous suivez ?

Answer 1

Je pense qu'il a tout à voir avec un bon style de codage. Bien sûr, vous pouvez écrire du bon, de solides programmes sans utiliser beaucoup d' final des modificateurs de n'importe où, mais quand vous pensez à ce sujet...

L'ajout d' final de toutes les choses qui ne devraient pas changer simplement réduit les possibilités que vous (ou le prochain programmeur, votre travail sur le code) interprètent mal ou de la mauvaise utilisation des processus de pensée qui a abouti dans votre code. Au moins, il devrait sonner quelques cloches quand ils veulent maintenant changer votre immuable précédemment chose.

Au premier abord, ça a l'air gêné de voir un grand nombre de final mots-clés dans votre code, mais bientôt vous allez arrêter de remarquer que le mot lui-même et tout simplement de penser, que-ce-sera-jamais-changement-de-ce-point-sur (vous pouvez le prendre de moi ;-)

Je pense que c'est une bonne pratique. Je ne suis pas l'utiliser tout le temps, mais quand je peux et ça fait sens pour désigner une chose en final je vais le faire.

Answer 2

Obséder:

• Final des champs - Marquage des champs de finale oblige à être réglée d'ici à la fin de la construction, ce qui rend ce champ de référence immuable. Cela permet de coffre-fort à la publication de champs et ne peut éviter la nécessité pour la synchronisation plus tard le lit. (Notez que pour un objet de référence, seul le champ de référence est immuable des choses que l'objet de référence se réfère à peut encore changer et qui affecte l'immutabilité.)
• Final champs statiques - Bien que j'ai utiliser les énumérations maintenant, pour beaucoup de cas où j'ai l'habitude d'utiliser static final champs.

Mais utiliser judicieusement:

• Final classes - Cadre/conception d'API est le seul cas où je considère qu'il est.
• Finale des méthodes Fondamentalement la même que final classes. Si vous utilisez la méthode de modèle modèles comme des fous et le marquage des trucs final, vous êtes probablement trop s'appuyer sur l'héritage et pas assez sur la délégation.

Ignorer, à moins que le sentiment anal:

• Méthode les paramètres et les variables locales, je fais RAREMENT ce en grande partie parce que je suis paresseux et je trouve cela encombre le code. Je reconnais que le marquage des paramètres et des variables locales que je ne vais pas à modifier est "plus juste". Je voudrais qu'il a été utilisé par défaut. Mais il n'est pas et j'ai trouver le code plus difficile à comprendre avec les finales de tous les coins. Si je suis chez quelqu'un d'autre code, je ne vais pas les sortir, mais si je suis en train d'écrire un nouveau code je ne vais pas les mettre dans. Une exception est le cas où vous devez marquer quelque chose de définitif, donc vous pouvez y accéder à partir de l'intérieur d'un anonyme intérieur de la classe.

Answer 3

Vous avez vraiment besoin de comprendre la pleine utilisation du mot clé final avant de l’utiliser. Il peut s’appliquer à et a affecte différentes sur les classes, champs, méthodes et variables

Je vous recommande de vérifier sur l’article du lien ci-dessous pour plus de détails.

Le mot final sur le mot clé final

Answer 4

L' final modificateur, en particulier pour les variables, est un moyen d'avoir le compilateur appliquer une convention qui est généralement sensible: assurez-vous d'un local (ou instance) de la variable est affectée exactement une fois (pas plus pas moins). En veillant à une variable est définitivement attribuées avant de l'utiliser, vous pouvez éviter de fréquents cas d'un NullPointerException:

final FileInputStream in;
if(test)
  in = new FileInputStream("foo.txt");
else
  System.out.println("test failed");
in.read(); // Compiler error because variable 'in' might be unassigned

En empêchant une variable d'être attribué plus d'une fois, vous décourager trop large portée. Au lieu de cela:

 String msg = null;
 for(int i = 0; i < 10; i++) {
     msg = "We are at position " + i;
     System.out.println(msg);
 }
 msg = null;

Vous êtes encouragés à utiliser ceci:

 for(int i = 0; i < 10; i++) {
     final String msg = "We are at position " + i;
     System.out.println(msg);
 }

Quelques liens:

• La dernière histoire (gratuit chapitre du livre "Hardcore Java")
• Certains modèles finaux
• Définitive d'attribution de

Answer 5

Java efficace a un article qui dit « Objets immuables de faveur ». Déclarant des champs comme définitive contribue à vous prendre quelques petites étapes dans cette direction, mais il y a bien sûr beaucoup plus d’objets vraiment immuables que celui.

Si vous savez que les objets sont immuables, elles peuvent être partagées pour la lecture parmi les nombreux sujets/clients sans soucis de synchronisation, et il est plus facile de raisonner sur la façon dont le programme s’exécute.