Discussion :

[qdaemon_fr]

Bonjour à tous

soit le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[unknow0]

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.

[Haywire]

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.

[adiGuba]

Salut,

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

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

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

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++

[JohnNC]

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

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

[adiGuba]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	private String value;
 
	public void setValue(String value) {
		value = value.toLowerCase();
	}

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++