Utilisation du modificateur «final» chaque fois qu'il est applicable en Java [fermé]

En Java, il existe une pratique de déclaration de chaque variable (locale ou classe), paramètre final si elles le sont vraiment.

Bien que cela rende le code beaucoup plus verbeux, cela facilite la lecture / saisie du code et empêche également les erreurs car l'intention est clairement indiquée.

Que pensez-vous de cela et que suivez-vous?

Je pense que tout cela a à voir avec un bon style de codage. Bien sûr, vous pouvez écrire de bons programmes robustes sans utiliser beaucoup de finalmodificateurs n'importe où, mais quand vous y pensez ...

Ajouter finalà tout ce qui ne devrait pas changer réduit simplement les possibilités que vous (ou le prochain programmeur travaillant sur votre code) interprétiez ou abusiez le processus de réflexion qui a abouti à votre code. Au moins, cela devrait sonner quelques cloches quand ils veulent maintenant changer votre chose auparavant immuable.

Au début, il semble un peu gênant de voir beaucoup de finalmots - clés dans votre code, mais bientôt vous cesserez de remarquer le mot lui-même et penserez simplement que cette chose ne changera jamais à partir de ce point. sur (vous pouvez le prendre de moi ;-)

Je pense que c'est une bonne pratique. Je ne l'utilise pas tout le temps, mais quand je peux et qu'il est logique d'étiqueter quelque chose, finalje le ferai.

Obséder sur:

• Champs finaux - Marquer les champs comme finaux les oblige à être définis à la fin de la construction, ce qui rend cette référence de champ immuable. Cela permet une publication sûre des champs et peut éviter le besoin de synchronisation lors de lectures ultérieures. (Notez que pour une référence d'objet, seule la référence de champ est immuable - les éléments auxquels la référence d'objet fait référence peuvent encore changer et cela affecte l'immuabilité.)
• Champs statiques finaux - Bien que j'utilise maintenant des énumérations dans de nombreux cas où j'utilisais des champs finaux statiques.

Considérez mais utilisez judicieusement:

• Classes finales - La conception de Framework / API est le seul cas où je le considère.
• Méthodes finales - Fondamentalement identiques aux classes finales. Si vous utilisez des modèles de méthode de modèle comme des trucs fous et de marquage final, vous comptez probablement trop sur l'héritage et pas assez sur la délégation.

Ignorer à moins de se sentir anal:

• Paramètres de méthode et variables locales - Je le fais RARELLEMENT en grande partie parce que je suis paresseux et je trouve que cela encombre le code. J'admettrai pleinement que le marquage des paramètres et des variables locales que je ne vais pas modifier est "plus juste". Je souhaite que ce soit la valeur par défaut. Mais ce n'est pas le cas et je trouve le code plus difficile à comprendre avec les finales partout. Si je suis dans le code de quelqu'un d'autre, je ne vais pas les retirer, mais si j'écris du nouveau code, je ne les mettrai pas. Une exception est le cas où vous devez marquer quelque chose de final pour que vous puissiez accéder à partir d'une classe interne anonyme.

Vous devez vraiment comprendre l'utilisation complète du mot-clé final avant de l'utiliser. Il peut s'appliquer et a des effets différents sur les variables, les champs, les méthodes et les classes

Je recommande de consulter l'article lié ci-dessous pour plus de détails.

Mot final Sur le mot clé final

Le finalmodificateur, en particulier pour les variables, est un moyen pour que le compilateur applique une convention qui est généralement sensée: assurez-vous qu'une variable (locale ou instance) est affectée exactement une fois (ni plus ni moins). En vous assurant qu'une variable est définitivement affectée avant d'être utilisée, vous pouvez éviter les cas courants de a 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 qu'une variable soit affectée plusieurs fois, vous découragez la portée trop large. 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;

Nous vous encourageons à utiliser ceci:

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

Quelques liens:

• L'histoire finale (chapitre gratuit du livre "Hardcore Java")
• Quelques schémas finaux
• Affectation définitive

Je suis assez dogmatique sur la déclaration de toutes les variables possibles final. Cela inclut les paramètres de méthode, les variables locales et rarement les champs d'objet de valeur. J'ai trois raisons principales pour déclarer des variables finales partout:

1. Déclaration d'intention: En déclarant une variable finale, j'affirme que cette variable ne doit être écrite qu'une seule fois. C'est un indice subtil pour les autres développeurs et un indice important pour le compilateur.
2. Application des variables à usage unique: je crois à l'idée que chaque variable ne devrait avoir qu'un seul but dans la vie. En ne donnant à chaque variable qu'un seul but, vous réduisez le temps nécessaire pour rechercher le but de cette variable particulière lors du débogage.
3. Permet l'optimisation: je sais que le compilateur avait des astuces d'amélioration des performances qui reposaient spécifiquement sur l'immuabilité d'une référence de variable. J'aime à penser que certaines de ces anciennes astuces de performance (ou de nouvelles) seront utilisées par le compilateur.

Cependant, je pense que les classes et méthodes finales ne sont pas aussi utiles que les références de variables finales. Le finalmot-clé, lorsqu'il est utilisé avec ces déclarations, fournit simplement des obstacles aux tests automatisés et à l'utilisation de votre code d'une manière que vous n'auriez jamais pu prévoir.

Java efficace a un élément qui dit "Favorisez les objets immuables". Déclarer des champs comme finaux vous aide à faire quelques petits pas dans ce sens, mais il y a bien sûr bien plus que des objets vraiment immuables.

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

Je n'ai jamais été dans une situation où avoir un mot-clé final sur une variable m'a empêché de faire une erreur, donc pour le moment je pense que c'est une énorme perte de temps.

À moins qu'il y ait une vraie raison de le faire (comme vous voulez faire un point spécifique sur le fait que cette variable soit finale), je préfère ne pas le faire car je trouve que cela rend le code moins lisible.

Si, cependant, vous ne trouvez pas que cela rend le code plus difficile à lire ou plus long à écrire, allez-y par tous les moyens.

Edit: Pour clarifier (et tenter de gagner des votes négatifs), je ne dis pas de ne pas marquer les constantes comme finales, je dis de ne pas faire des choses comme:

public String doSomething() {
  final String first = someReallyComplicatedExpressionToGetTheString();
  final String second = anotherReallyComplicatedExpressionToGetAnother();

  return first+second;
}

Cela rend le code (à mon avis) plus difficile à lire.

Il convient également de se rappeler que tout ce que fait la finale est de vous empêcher de réaffecter une variable, cela ne la rend pas immuable ou quelque chose comme ça.

Final doit toujours être utilisé pour les constantes. Il est même utile pour les variables de courte durée (au sein d'une même méthode) lorsque les règles de définition de la variable sont compliquées.

Par exemple:

final int foo;
if (a)
    foo = 1;
else if (b)
    foo = 2;
else if (c)
    foo = 3;
if (d)        // Compile error:  forgot the 'else'
    foo = 4;
else
    foo = -1;

On dirait que l'un des plus gros arguments contre l' utilisation du mot-clé final est que "c'est inutile" et qu'il "gaspille de l'espace".

Si nous reconnaissons les nombreux avantages de "final" comme le soulignent de nombreux articles ici, tout en admettant qu'il faut plus de frappe et d'espace, je dirais que Java aurait dû rendre les variables "finales" par défaut, et exiger que les choses soient marquées " mutable "si le codeur le souhaite.

J'utilise finaltout le temps pour les attributs d'objet.

Le finalmot-clé a une sémantique de visibilité lorsqu'il est utilisé sur des attributs d'objet. Fondamentalement, la définition de la valeur d'un attribut d'objet final se produit avant le retour du constructeur. Cela signifie que tant que vous ne laissez pas la thisréférence s'échapper du constructeur et que vous l'utilisez finalpour tous vos attributs, votre objet est (sous la sémantique Java 5) garanti pour être correctement construit, et puisqu'il est également immuable, il peut être publié en toute sécurité à d'autres threads.

Les objets immuables ne concernent pas uniquement la sécurité des threads. Ils facilitent également beaucoup la réflexion sur les transitions d'état dans votre programme, car l'espace de ce qui peut changer est délibérément et, s'il est utilisé de manière cohérente, complètement limité aux seules choses qui devraient changer.

Je fais parfois des méthodes définitives, mais pas aussi souvent. Je fais rarement des cours finaux. Je le fais généralement parce que j'en ai peu besoin. Je n'utilise généralement pas beaucoup l'héritage. Je préfère utiliser des interfaces et la composition d'objets à la place - cela se prête également à un design que je trouve souvent plus facile à tester. Lorsque vous codez pour des interfaces au lieu de classes concrètes, vous n'avez pas besoin d'utiliser l'héritage lorsque vous testez, tel quel, avec des frameworks tels que jMock, beaucoup plus facile de créer des objets fantômes avec des interfaces qu'avec des classes concrètes.

Je suppose que je devrais faire la majorité de mes cours en finale, mais je ne suis pas encore entré dans l'habbit.

Je dois lire beaucoup de code pour mon travail. Manquer la finale sur les variables d'instance est l'une des principales choses qui me dérange et rend la compréhension du code inutilement difficile. Pour mon argent, la finale sur les variables locales cause plus d'encombrement que de clarté. Le langage aurait dû être conçu pour en faire la valeur par défaut, mais nous devons vivre avec l'erreur. Parfois, il est utile en particulier avec les boucles et l'affectation définitive avec un arbre if-else, mais il tend généralement à indiquer que votre méthode est trop compliquée.

final devrait évidemment être utilisé sur les constantes, et pour imposer l'immuabilité, mais il y a une autre utilisation importante sur les méthodes.

Java efficace a un élément complet à ce sujet (article 15) soulignant les pièges de l'héritage involontaire. En effet, si vous n'avez pas conçu et documenté votre classe pour l'héritage, l'hériter peut créer des problèmes inattendus (l'élément donne un bon exemple). Il est donc recommandé d'utiliser final sur toute classe et / ou méthode qui n'était pas destinée à être héritée.

Cela peut sembler draconien, mais cela a du sens. Si vous écrivez une bibliothèque de classes pour une utilisation par d'autres, vous ne voulez pas qu'elle hérite de choses qui n'ont pas été conçues pour elle - vous vous enfermerez dans une implémentation particulière de la classe pour une compatibilité descendante. Si vous codez dans une équipe, rien n'empêche un autre membre de l'équipe de retirer la finale s'il le faut vraiment. Mais le mot-clé les fait réfléchir à ce qu'ils font et les avertit que la classe dont ils héritent n'a pas été conçue pour cela, ils doivent donc être très prudents.

Une autre mise en garde est que beaucoup de gens confondent final pour signifier que le contenu de la variable d'instance ne peut pas changer, plutôt que la référence ne peut pas changer.

Même pour les variables locales, sachant qu'il est déclaré final signifie que je n'ai pas besoin de m'inquiéter que la référence soit modifiée plus tard. Cela signifie que lors du débogage et que je vois cette variable plus tard, je suis convaincu qu'elle fait référence au même objet. C'est une chose de moins dont je dois m'inquiéter lors de la recherche d'un bug. Un avantage est que si 99% des variables sont déclarées définitives, alors les quelques variables qui sont vraiment variables ressortent mieux. En outre, la finale permet au compilateur de trouver d'autres erreurs stupides possibles qui pourraient autrement passer inaperçues.

Choisir de taper final pour chaque paramètre dans chaque méthode produira tellement d'irritation à la fois pour les codeurs et les lecteurs de code.

Une fois que l'irritation dépasse le cadre raisonnable, passez à Scala où les arguments sont définitifs par défaut.

Ou, vous pouvez toujours utiliser des outils de style de code qui le feront automatiquement pour vous. Tous les IDE les ont implémentés ou en tant que plugins.

Final, lorsqu'il est utilisé avec des variables en Java, remplace la constante en C ++. Ainsi, lorsque final et static est utilisé pour une variable, elle devient immuable. En même temps, les programmeurs C ++ migrés sont très heureux ;-)

Lorsqu'il est utilisé avec des variables de référence, il ne vous permet pas de re-référencer l'objet, bien que l'objet puisse être manipulé.

Lorsque final est utilisé avec une méthode, il ne permet pas à la méthode d'être écrasée par les sous-classes.

Une fois que l'utilisation est très claire, elle doit être utilisée avec soin. Cela dépend principalement de la conception car l'utilisation finale de la méthode n'aiderait pas le polymorphisme.

On ne devrait l'utiliser pour les variables que lorsque l'on est sacrément sûr que la valeur de la variable ne sera / ne devrait jamais être modifiée. Assurez-vous également que vous suivez la convention de codage encouragée par SUN.for par exemple: final int COLOR_RED = 1; (Majuscules séparés par un trait de soulignement)

Avec une variable de référence, utilisez-la uniquement lorsque nous avons besoin d'une référence immuable à un objet particulier.

Concernant la partie sur la lisibilité, assurez-vous que les commentaires jouent un rôle très important lors de l'utilisation du modificateur final.

Je ne les utilise jamais sur des variables locales, il n'y a pas grand chose à ajouter à la verbosité. Même si vous ne pensez pas que la variable doit être réaffectée, cela fera peu de différence pour la prochaine personne qui modifie ce code qui pense le contraire, et puisque le code est en cours de modification, tout objectif initial pour le rendre définitif peut ne plus être valide. Si c'est juste pour la clarté, je pense que cela échoue en raison des effets négatifs de la verbosité.

À peu près la même chose s'applique également aux variables membres, car elles offrent peu d'avantages, à l'exception du cas des constantes.

Cela n'a pas non plus d'incidence sur l'immuabilité, car le meilleur indicateur que quelque chose est immuable est qu'il est documenté comme tel et / ou n'a pas de méthodes qui peuvent altérer l'objet (ceci, en plus de rendre la classe finale, est le seul moyen de garantir que il est immuable).

Mais bon, c'est juste mon avis :-)

J'ai configuré Eclipse pour ajouter final sur tous les champs et attributs qui ne sont pas modifiés. Cela fonctionne très bien en utilisant les "actions de sauvegarde" d'Eclipse qui ajoutent ces derniers modificateurs (entre autres) lors de l'enregistrement du fichier.

Hautement recommandé.

Consultez mon article de blog sur les actions de sauvegarde Eclipse.

Pour les arguments, je pense qu'ils ne sont pas nécessaires. Surtout, ils ont juste nui à la capacité de réadaptation. Réaffecter une variable d'argument est tellement stupide que je devrais être assez sûr qu'ils peuvent être traités comme des constantes de toute façon.

Le fait que Eclipse colore le rouge final facilite le repérage des déclarations de variables dans le code, ce qui, je pense, améliore la lisibilité la plupart du temps.

J'essaie de faire respecter la règle selon laquelle toutes les variables doivent être définitives s'il n'y a pas de raison extrêmement valable de ne pas le faire. Il est tellement plus simple de répondre à la question "quelle est cette variable?" question si vous avez juste à trouver l'initiation et être sûr que c'est tout.

En fait, je suis plutôt nerveux à propos des variables non finales depuis quelques jours. C'est comme la différence entre avoir un couteau accroché dans un fil au-dessus de votre tête ou simplement l'avoir dans votre tiroir de cuisine ...

Une variable finale est juste un bon moyen de marquer des valeurs.

Une variable non finale est liée à une partie d'un algorithme sujet aux bogues.

Une fonctionnalité intéressante est que lorsque l'option d'utiliser une variable hors de question pour un algorithme la plupart du temps, la sollicution consiste à écrire une méthode à la place, ce qui améliore généralement le code de manière significative.

J'ai codé pendant un certain temps maintenant et j'utilise final chaque fois que je le peux. Après avoir fait cela pendant un certain temps (pour les variables, les paramètres de méthode et les attributs de classe), je peux dire que 90% (ou plus) de mes variables sont en fait finales. Je pense que l'avantage de ne PAS avoir de variables modifiées lorsque vous ne le souhaitez pas (je l'ai déjà vu et c'est parfois pénible) paie pour la frappe supplémentaire et les mots clés "finaux" supplémentaires dans votre code.

Cela étant dit, si je concevais un langage, je rendrais chaque variable finale à moins qu'elle ne soit modifiée par un autre mot clé.

Je n'utilise pas beaucoup la finale pour les cours et les méthodes, pensais-je. C'est un choix de conception plus ou moins compliqué, sauf si votre classe est une classe utilitaire (auquel cas vous ne devriez avoir qu'un seul constructeur privé).

J'utilise également Collections.unmodifiable ... pour créer des listes non modifiables quand j'en ai besoin.

L'utilisation de classes locales anonymes pour les écouteurs d'événements et autres est un modèle courant en Java. L'utilisation la plus courante du mot clé final est de s'assurer que les variables de portée sont accessibles à l'écouteur pair.

Cependant, si vous vous trouvez obligé de mettre beaucoup de déclarations finales dans votre code. Cela pourrait être un bon indice que vous faites quelque chose de mal.

L'article publié ci-dessus donne cet exemple:

public void doSomething(int i, int j) {
    final int n = i + j; // must be declared final

    Comparator comp = new Comparator() {
        public int compare(Object left, Object right) {
            return n; // return copy of a local variable
        }
    };
}

Je l'utilise pour les constantes à l'intérieur et à l'extérieur des méthodes.

Je ne l'utilise que parfois pour les méthodes parce que je ne sais pas si une sous-classe ne voudrait PAS remplacer une méthode donnée (pour une raison quelconque).

En ce qui concerne les classes, uniquement pour certaines classes d'infrastructure, ai-je utilisé la classe finale.

IntelliJ IDEA vous avertit si un paramètre de fonction est écrit dans une fonction. J'ai donc cessé d'utiliser final pour les arguments de fonction. Je ne les vois pas également dans la bibliothèque java Runtime.

J'utilise à peine final sur des méthodes ou des classes parce que j'aime permettre aux gens de les remplacer.

Sinon, je n'utilise finalement que si c'est un public/private static final type SOME_CONSTANT;

Le marquage de la classe finale peut également provoquer certaines liaisons de méthode au moment de la compilation plutôt qu'à l'exécution. Considérez "v2.foo ()" ci-dessous - le compilateur sait que B ne peut pas avoir de sous-classe, donc foo () ne peut pas être surchargé donc l'implémentation à appeler est connue au moment de la compilation. Si la classe B n'est PAS marquée comme finale, alors il est possible que le type réel de v2 soit une classe qui étend B et remplace foo ().

class A {
    void foo() {
        //do something
    }
}
final class B extends A {
    void foo() {
    }
}
class Test {
    public void t(A v1, B v2) {
        v1.foo();
        v2.foo();
    }
}

L'utilisation de final pour les constantes est fortement encouragée. Cependant, je ne l'utiliserais pas pour les méthodes ou les classes (ou du moins y penser pendant un certain temps), car cela rend les tests plus difficiles, voire impossibles. Si vous devez absolument rendre une classe ou une méthode définitive, assurez-vous que cette classe implémente une interface, afin que vous puissiez avoir une maquette implémentant la même interface.