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

194

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?

surajs
la source
13
Cela peut conduire à un argument religieux. Certaines personnes aiment ça, certaines personnes détestent ça. J'aime les champs finaux mais pas les variables locales finales à moins qu'elles ne le soient, je ne suis pas sûr que ce soit entièrement rationnel. Je ne suis pas sûr qu'un vote à la baisse soit non plus. Je suis d'accord avec Alex Miller. ;)
Peter Lawrey
Je peux comprendre si les gens n'aiment pas que leur code soit encombré de finales. Mais c'est un problème qu'un bon éditeur pourrait résoudre: bugs.eclipse.org/bugs/show_bug.cgi?id=409379
oberlies

Réponses:

184

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.

Johan Pelgrim
la source
16
Au lieu d'utiliser le mot-clé final pour les paramètres, vous pouvez utiliser un outil d'analyse statique tel que FindBugs pour exiger que les variables de paramètre ne soient pas réaffectées. De cette façon, vous supprimez la charge syntaxique et pouvez l'imposer via une vérification FindBugs dans votre outil d'intégration continue.
Timo Westkämper
20
@Timo Cela fonctionnerait, mais il a l'inconvénient que cela doit être vérifié après l'archivage et non pendant que le développeur travaille sur le code. Car final, le compilateur ne vous laissera évidemment pas continuer si vous faites une erreur.
Mike
9
Eclipse a une option pour ajouter finalautant que possible (variables qui ne changent pas) chaque fois que vous enregistrez.
Bert F
22
+1 J'adore final. Cela ne fait pas de différence 98% du temps, c'est un inconvénient mineur% 1 du temps, mais le 1% du temps qui m'évite de faire quelque chose de stupide ou involontaire en vaut la peine.
Bert F
14
@BertF Oui, je laisse toujours Eclipse ajouter des finalmodificateurs partout quand je "nettoie ..." mon code. Partout signifie même dans les blocs catch (), et comme dit, vous ne les remarquerez pas après un certain temps. Bien sûr, si je créais une langue, ce finalserait la valeur par défaut, et a varou modifiableserait le mot-clé facultatif.
Maarten Bodewes
191

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.
Alex Miller
la source
8
meilleure réponse à ce jour pour plusieurs questions sur ce dernier sujet
Gabriel Ščerbák
4
La plupart du temps, lorsque je vois une variable locale sans mot final devant elle et qu'elle ne peut pas être utilisée ici, cela me dit que je devrais probablement extraire du code dans une nouvelle méthode qui renvoie la valeur souhaitée que je rendrai finale. Les cas où cela ne s'applique pas, c'est lorsque j'utilise certains flux ou que j'ai besoin d'essayer de l'attraper.
nyxz
32

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

HowardSP
la source
29

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:

Bruno De Fraine
la source
1
+1 pour décourager l'argument de la portée internationale
Tom Tresansky
En bref, vous pouvez utiliser essentiellement finalpour rendre Java plus basé sur l'expression .
Adam Gent
En fait "En vous assurant qu'une variable est définitivement affectée avant d'être utilisée, vous pouvez éviter les cas courants de NullPointerException:" ce n'est pas correct, 'final' ne fait aucune différence ici, le compilateur connaît et se plaint éventuellement de la variable 'in' étant nul dans l'exemple fourni.
nyholku
@nyholku Vous avez raison, en Java les variables locales doivent être définitivement affectées avant utilisation, également sans final. Mais pour les domaines, vous avez besoin de la finale. Dans un exemple un peu plus complexe où "in" est une variable d'instance d'une classe, et si / else est dans le constructeur, vous avez besoin du final pour signaler le problème. De plus, également pour les variables locales, il y a une certaine valeur dans l'OMI final, car cela empêche le programmeur bâclé de «corriger» l'erreur de compilation sur «in» pouvant être non affectée en ajoutant «= null» à sa déclaration. En d'autres termes, selon mon expérience, les variables finales réduisent les utilisations de null.
Bruno De Fraine
20

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.

Ryan Ransford
la source
2
finalles variables et les paramètres de méthode n'ont aucun impact sur les performances car ils ne sont pas exprimés dans le bytecode.
Steve Kuo
variable: = latin: varius> divers> modifiable
diète
17

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.

Lars Westergren
la source
15
attention - final et immuable sont des concepts complètement différents. Il est facile d'avoir un objet mutable final - final concerne la référence, la mutabilité concerne l'instance d'objet. dernière personne olaf = nouvelle personne (); olaf.setName ("Olaf");
Olaf Kock
1
Exactement - les objets immuables sont une chose, les références immuables (c'est-à-dire finales) en sont une autre.
SCdF
2
Mais ils sont étroitement liés puisque vous pouvez en déclarant le champ Person.name final (et en déclarant la classe finale, et ...) rendre l'objet Person final. Ce n'est cependant pas aussi simple que de faire "la dernière personne" ...
Sebastian Ganslandt
Cela n'est pas non plus pertinent pour les variables locales (les paramètres sont des variables locales). Il ne s'applique qu'aux variables de classe et ne répond donc que partiellement à la question.
Robin
12

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.

SCdF
la source
1
Renverser la déclaration: j'ai été dans de nombreuses situations où la non- utilisation final(et les objets immuables en général) a eu un facteur contributif important au nombre et à l'impact des bogues.
Chris Vest
3
Je suis pour les objets immuables, je n'ai jamais été dans une situation où le marquage final d'un objet immuable m'a aidé.
SCdF
2
Je suis d'accord que nous ne devrions pas utiliser final sur les variables locales et les paramètres de méthode, cela rend le code beaucoup moins lisible.
rmaruszewski
@ChrisVest, vos fonctions sont peut-être trop longues
Pacerier
8

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;
David Leppik
la source
6

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.

RAYON
la source
1
Downvoters, souci d'expliquer?
RAY
Cela semble étrange de l'appeler alors une variable, n'est-ce pas?
Alan
2
Il y a des milliers de mots anglais à choisir.
RAY
C'est parfait. Il n'y a aucun argument contre finalà part "trop ​​de temps pour écrire", "rend le code plus maladroit". Il y a plusieurs arguments pour final. Et nous pouvons l'ajouter automatiquement lors de la sauvegarde, si vous ne voulez pas le taper à la main.
Dmitriy Popov
5

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.

Chris Vest
la source
4

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.

Tom Hawtin - sellerie
la source
Pourquoi ne pas utiliser un outil qui réduit l'encombrement?
Pacerier
@Pacerier Comme dans un éditeur qui déforme le code?
Tom Hawtin - tackline
3

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.

DJClayworth
la source
3

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.

Uri
la source
Et ce message en est une grande preuve.
inigoD
2

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.

Diastrophisme
la source
2

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.

Oleg Mikheev
la source
1

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.

Omnipotent
la source
Quelqu'un peut-il me dire pourquoi ce vote est rejeté ??? Juste curieux ..
Omnipotent
C'est probablement parce que vous déclarez que vous ne devez le rendre final que lorsque XYZ. D'autres considèrent qu'il est préférable de TOUT rendre définitif à moins qu'il ne soit nécessaire de le faire autrement.
Programmeur hors
1
Ce n'est pas du tout un substitut au mot-clé const C ++. -1.
tmj
1

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 :-)

Robin
la source
1

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.

zvikico
la source
1

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.

John Nilsson
la source
1

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.

Ravi Wallau
la source
0

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
        }
    };
}
Hans Sjunnesson
la source
0

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.

anjanb
la source
0

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;

jjnguy
la source
Hmm..édité à un seul endroit..encore dit enfin sur la deuxième ligne ;-)
Omnipotent
Permettre aux gens de remplacer les valeurs est la plus grande source de surprises et de bugs difficiles à comprendre
RAY
0

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();
    }
}
Eugène
la source
-1

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.

Paweł Hajdan
la source
Cela ne rend pas les tests plus difficiles car vous devriez quand même utiliser des interfaces.
Chris Vest