septembre
2009
Un article de benwit
Avec ce billet, j’ai envie d’introduire des petites questions de style que l’on se pose parfois.
Comme tout acte d’écriture, chaque développeur possède son style de codage.
Ce style se forge avec le temps
- en suivant le style de nos maîtres
- en suivant les conventions qui rendent un travail d’équipe plus homogène
- en suivant nos propres choix …
Parfois, ces choix sont purement arbitraires (les alternatives se valent, les avantages de l’une compensent les inconvénients de l’autre et vice-versa)
D’autre fois, de bonnes pratiques émergent avec l’expérience …
Quoi qu’il en soit, si l’essentiel est de rester cohérent, réfléchir à la question ne peut être que bénéfique pour comprendre une convention existante ou pour créer la nôtre.
« This » is the first question …
Que faites vous avec « this » ?
Dans certains cas, ce mot clé est incontournable et la question ne se pose pas.
Mais lorsqu’il n’est pas nécessaire, faut t’il l’utiliser ?
=> Débutant, je l’ai découvert dans les mutateurs (setters) :
- soit on s’en passe et il faut trouver un nom pour le paramètre différent du nom de la variable d’instance.
- soit on l’utilise et on conserve un même nom.
Aujourd’hui, avec la génération par les IDE, le deuxième choix semble le plus répandu.
=> Pendant une période, j’aimai bien l’utiliser systématiquement pour distinguer d’un coup d’oeil mes variables d’instance des autres variables.
Certains font cela avec des conventions de nommage des variables (préfixée par _ par exemple).
=> Puis, parce que l’IDE m’affichait ces variables dans une couleur dédiée, je m’en suis de nouveau remis à l’implicite, gardant le mot « this » uniquement où c’était requis.
=> Dernièrement, en faisant du refactoring, je me suis rendu compte que j’évitais potentiellement des erreurs si j’avais utilisé « this » explicitement.
Et vous, que faites vous ? et pourquoi ?
@kazou : je disais justement que l’on a affaire à deux problèmes différents. Le seul rapport est l’usage ou non de this dans les mutateurs (getters/setters).
@benwit : ok, c’était quelque chose de bien spécifique. lol
M’enfin, ça a servi tout de même 
@zedros
1) Si je te comprend bien, tu fais état d’une autre question (Doit t’on au sein d’une classe attaquer directement les variables d’instances ou passer par les setters/getters) et effectivement, c’est un problème différent de celui que j’évoque ici. (Mais ta réponse est intéressante)
Je faisais juste état de : void setTruc(int truc){this.truc=truc;} VS void setTruc(int unTruc){truc= unTruc;} et disais « attention au refactoring de truc en unTruc ! »
2) Merci de l’astuce eclipse (comme quoi, ce petit billet m’a enrichi !!!), je n’avais pas pensé à regardé de ce côté et je vais probablement le passer à Always pour le même genre de surprise que toi ;o)
@zedros : Je ne suis pas sûr de bien te suivre, quel est le rapport avec this ?
La paradigme d’encapsulation est bien connu et comme tu le démontre dans ta réponse, la tâche est plus compliqué qu’il n’y parait. Mais quel rapport avec this ?
Hum, concernant this et les setters, je dirai que c’est 2 problèmes différents : this ne concerne que les appels depuis l’objet lui même, alors que les setters/getters concernent aussi les appels extérieurs.
En suivant la logique objet, on veut encapsuler les variables membres, histoire d’éviter que l’extérieur fasse n’importe quoi avec. D’où les getters/setters, mais cela n’implique nullement que depuis la classe même on ne puisse pas appeler directement les attributs. Au contraire même !
En effet, si tu as un objet membre, tu ne veux sans doute pas qu’un autre bout de code puisse le modifier (qui sait en même temps qu’un autre bout de code, ou en le rendant nul…). Du coup, il est commun de passer une copie ou une « unmodifiableList » en retour d’un getter. Inversement, pour les setters, tu veux sans doute t’assurer que le monde extérieur respecte le contrat de ton attribut (non nul, valeur positive…). Tout ça implique qu’au sein de ta classe tu préfères passer directement par la variable.
Concernant this, tu peux aussi demander à eclipse de les mettre tout le temps ou quand nécessaire, via Windows/preferences/Java/Editor/Save actions/Configure/Member Access/Use this qualifier for field accesses « Always/If necessary » (en anglais dans mon eclipse, dsl). D’ailleurs je suis en train de me demander si je ne devrai pas passer à Always, vu que j’ai aussi eu parfois qq surprises avec des attributs pris pour des variables membres de ma classe.
Pour ce qui du this, je ne l’utilise que très rarement dans le code que j’écris, mais je le laisse automatiquement dans les setters qui sont auto-générés par mon IDE