final dans les variables d'une méthode

Bonjour à tous

soit le code suivant :

Code:

---

1 2 3 4 5 6 7 8

final CResources resources = x.Get_Resources(); final int resourcesCount = resources.Get_Count(); for (int i = 0; i < resourcesCount; i++) { final String resourceId = resources.Get_Tag(i); final CRoutes routes = resources.Get_Routes(i, -1); final int WorkDayCount = Integer.valueOf(resources.Get_Details(i)); for (int j = 0; j < WorkDayCount; j++) {

---

J'ai déclaré tout en constantes, je n'ai effectivement pas besoin de les
modifier après leur création.
Ma question porte plutôt sur les us et coutumes de la programmation Java.
Outre l'aspect erreur de compilation en cas de réaffectation, y-a-t il qq
chose à gagner (temps de traitement, mémoire...) à faire ainsi ?

Les bonnes pratiques de la programmation Java sont elles plutôt orientées vers
ce genre de solution ou plutôt à laisser les déclaration sans final ?

merci
Julien

Bonjour,

Personnellement je ne met des final que si cette variable doit etre une constante.
La dans ton code tes varibla n'on pas de reson d'etre final donc je n'en metrait pas.

Pour les gains je pence que le compilateur et plus douer que nous pour ce genre d'optimisation. Le compilo déclarera les variable final si il y a un gain.

Cordialement.

Personnellement je ne déclare final que des variables d'instance de type primitif, ou des "constantes d'instance".

Au boulot j'ai remarqué que pas mal de méthodes sont déclarées avec des paramètres final. Je ne sais pas pourquoi mais je n'ai pas ce réflexe en java alors que je le faisais systématiquement en Delphi quand je ne voulais pas modifier la valeur dans la méthode.
Sans doute parce qu'en delphi on se pose toujours la question de savoir si on met "var", "const" ou rien du tout. L'absence de pointeur en java fait que je n'y pense pas.
En delphi en tout cas je sais que le compilo optimise lorsqu'on utilise const, en java je ne sais pas.

Salut,

Citation:

---

Envoyé par unknow0

Personnellement je ne met des final que si cette variable doit etre une constante.
La dans ton code tes varibla n'on pas de reson d'etre final donc je n'en metrait pas.

---

Pour une constante c'est effectivement très utile car le compilateur supprimera carrément la variable pour la remplacer par sa valeur.


Maintenant dans le cas d'objet ou de primitifs "non-constante", cela permet de clarifier le code pour le developpeur : on sait que la variable ne sera plus affecté dans le code ;)

Citation:

---

Envoyé par unknow0

Pour les gains je pence que le compilateur et plus douer que nous pour ce genre d'optimisation. Le compilo déclarera les variable final si il y a un gain.

---

Oui il y a de forte chance qu'il le fasse quand même...

Attention : en ce qui concerne les variables locales seulement : pour les attributs d'instance ou static le final est obligatoire pour que le compilateur puisse optimiser les accès à la variable ;)

Citation:

---

Envoyé par Mushroom7

Au boulot j'ai remarqué que pas mal de méthodes sont déclarées avec des paramètres final.

---

Cela permet d'éviter les réaffections érronés ;)

Citation:

---

Envoyé par Mushroom7

En delphi en tout cas je sais que le compilo optimise lorsqu'on utilise const, en java je ne sais pas.

---

Java peut optimiser les variables locales finales (y compris les paramètres), mais sauf erreur il le fait très bien même sans le mot-clef final si elles ne sont pas modifié pendant le traitement ;)

a++

Citation:

---

Envoyé par Mushroom7

Au boulot j'ai remarqué que pas mal de méthodes sont déclarées avec des paramètres final.

---

Citation:

---

Envoyé par adiGuba

Cela permet d'éviter les réaffections érronés ;)

---

Par réaffectation, tu entends bien "surcharge" ("final" sur une méthode), non ?

Citation:

---

Envoyé par JohnNC

Par réaffectation, tu entends bien "surcharge" ("final" sur une méthode), non ?

---

Non non je parle d'affectation de variable.
Exemple tout con qui ne provoque pas d'erreur :

Code:

---

1 2 3 4 5

private String value;   public void setValue(String value) { value = value.toLowerCase(); }

---

:arrow: On a simplement oublier le this sur l'affectation de l'attribut d'instance, et du coup à cause du conflit de nom on fait l'affectation sur le paramètre ce qui est une erreur dans ce cas précis... mais qui passe à la compilation !

En déclarant le paramètre final on aurait eu une belle erreur du compilateur pour nous prévenir du problème ;)

a++

J'avais lu quelque part que la machine virtuelle était autorisée à faire des optimisations agressives à la rencontre du mot clef final, mais impossible de retrouver la référence ; je m'en souviens juste parce que je m'étais demandé ce que pouvait bien être une optimisation agressive, en anglais dans le texte.

Je suis POUR l'usage de ce terme car je me rends compte qu'il favorise la réflexion sur la construction d'un objet, sur la façon de faire évoluer son code, qu'il favorise la lisibilité du code. J'aimerais qu'il y ait plus de termes comme ça dans le langage.

Mais c'est comme tout ; le jour où il y aura des outils qui compteront le nombre de final et en sortiront des stats qualité, ce sera fichu ; il faut l'employer de façon appropriée, et on discute sur quand c'est approprié, par rapport au sens ou à l'usage, non par rapport au nombre de lignes, non sur l'outil qui compte le plus vite, il ne s'agit pas de dire qu'il faut l'employer systématiquement.

Il est approprié lorsque par politique on décide de profiter de la fiabilité qu'il donne (cas du String, ou des clefs des hash), lorsque l'on veut manifester qu'une variable n'est employée que dans un seul but ; il ne l'est pas lorsque on peut changer l'affectation d'une variable sans changer son but (cas par exemple du texte des JLabel).

Liens qui me paraissent bien : final (Java), final : Java Glossary.

Etc.

(à noter que final ne protège pas de toutes les modifs, un geek fou saura modifier la valeur d'une variable final).

Ok, merci de vos réponses.

Julien