Discussion :

[Targan]

Bonjour,

je n'ai pas une énorme expérience en java, et la plupart du temps sur Netbeans (vieille version Unix ).

Je viens de passer sous Eclipse, et celui-ci est franchement plus sympathique, mais me fait des refactoring que je ne comprends pas toujours.

Je souhaiterai avoir votre avis donc sur quelques bonne pratiques :

- est il nécessaire de mettre à chaque fois "this." pour affecter un attribut de la classe courante ? il me semblait que ce n'était fait que si y avait un doute par rapport à un paramètre portant le même nom.
Ce n'est peut être pas obligatoire, mais est ce que cela devient courant de les mettre à chaque fois pour faciliter la lecture et la compréhension en cas de reprise du code ?
Quelles bonnes pratiques à avoir ? Est il courant de tout mettre à this. si y a un mélange dans une méthode ?

- Eclipse en créant un getter et un setter d'un attribut, que j'avais déjà affecté dans d'autres méthodes, est allé modifier le code pour faire un appel au setter.
Pourquoi ?
Là encore, les getters & setter me semblent utiles pour des appels externes à la classe. Pourquoi en interne privilégie-t-il cela ?

Merci.

[Noctis]

Bonjour,

Pour ma part, j'utilise le "this." que lorsqu'on passe un parametre d'une methode ayant le meme nom qu'un attribut de classe. Sinon celui ci est implicite.
Inutile de charger le code avec des this pour tous les attributs... la relecture deviendrais vite penible je pense

Concernant ton deuxième point, tu declares bien tes attributs private ?

[Targan]

Oui mes attributs sont private.

Donc je comprends bien que les seuls accès sont les setter & getter. Mais pas en interne généralement.....

Je pose toutes ces questions car je viens de découvrir des subtilités qui se sont "inversées" d'une version à l'autre de java (ex: marquer toutes les méthodes @Override d'une classe d'implémentation d'une interface alors que cela n'était pas nécessaire auparavant, maintenant c'est warning).

[Népomucène]

Donner les accès aux attributs privés utilisés uniquement en interne via des "getter" et "setter" ne me semble pas être utile.

Cela peut éventuellement se justifier si un attribut est utilisé en interne ET accessible par d'autres classes.
Dans ce cas, il faut certainement utiliser synchronised dans les "getter" et "setter" et donc alors l'utilisation en interne doit passer par ces méthodes

sinon, pour ta gouverne, les dernières versions de NetBeans donne le choix d'accès ou non par getter pour l'usage interne.
Mais ça c'est parce que j'aime bien NB, je suis donc partial.

[JoeChip]

Pistes de réflexion : http://codemonkeyism.com/generation-...ramming-style/

Il ne faut pas forcément obéir à Eclipse, c'est lui qui doit t'obéir, c'est comme un GPS...

[Népomucène]

Pistes de réflexion : http://codemonkeyism.com/generation-...ramming-style/

J'ai suivi le lien.
Franchement quand il dit qu'il ne faut pas du tout utiliser de setters,
il se fourvoie complètement pour les raisons évoquées dans les posts précédents.

Encore une autre raison d'utiliser getters/setters est que c'est la norme "beans".
C'est le cas si je veux ajouter des composants personnalisés à un IDE
car celui-ci s'attend à avoir un getter/setter sur chaque attribut pour pouvoir le manipuler.

Je pense que @Targan avait besoin de savoir quels types de raisons il y a pour programmer de cette façon.
On lui en a donné un aperçu - non exhaustif - qui lui permettra de "doser" les getters/setters

[deathness]

Donner les accès aux attributs privés utilisés uniquement en interne via des "getter" et "setter" ne me semble pas être utile.

Cela peut éventuellement se justifier si un attribut est utilisé en interne ET accessible par d'autres classes.
Dans ce cas, il faut certainement utiliser synchronised dans les "getter" et "setter" et donc alors l'utilisation en interne doit passer par ces méthodes

sinon, pour ta gouverne, les dernières versions de NetBeans donne le choix d'accès ou non par getter pour l'usage interne.
Mais ça c'est parce que j'aime bien NB, je suis donc partial.

Un interêt des getter, setter interne ou non:
- avoir facilement une trace de tout accès et modification d'un attribut, pour un log ou pour du debug

[Targan]

Donner les accès aux attributs privés utilisés uniquement en interne via des "getter" et "setter" ne me semble pas être utile.

Cela peut éventuellement se justifier si un attribut est utilisé en interne ET accessible par d'autres classes.
Dans ce cas, il faut certainement utiliser synchronised dans les "getter" et "setter" et donc alors l'utilisation en interne doit passer par ces méthodes

sinon, pour ta gouverne, les dernières versions de NetBeans donne le choix d'accès ou non par getter pour l'usage interne.
Mais ça c'est parce que j'aime bien NB, je suis donc partial.

Je suis un peu dans un cas comme celui là effectivement.

Je suis sur une classe de type "ViewModel" pour une utilisation dans un pattern MVVM. J'ai justement des attributs à mettre, avec des getters & setters (je présume que cela impose même le fait de devoir utiliser getXX et setXX, faudrait que je teste pour voir si cela fonctionne avec un getter style isXX pour des booleans mais j'en doute :p).

Sur les setters, y a une annotation qui permet de "mettre à jour" l'interface graphique quand un appel est réalisé. Tout est automatisé, je ne fais pas d'appel manuel donc les synchronized ne sont pas forcément utile.
Cela expliquerait peut être pourquoi Eclipse veut mettre des appels aux setters, au lieu de modifier directement l'attribut....maintenant j'ai la possibilité de mettre une annotation pour indiquer la mise à jour de mon attribut dans ma méthode tierce qui le modifie. Donc je peux parfaitement me passer du setter.

Anyway, merci pour l'article, c'est très intéressant même si j'avoue que je suis aussi perplexe sur certains points.

[Népomucène]

Je te confirme que le getter pour un boolean est bien de la forme isXXXX.

[Targan]

Je te confirme que le getter pour un boolean est bien de la forme isXXXX.

Certes, mais je ne suis pas sur que le framework qui "bind" la propriété (en EL expression) via les getters & setters puisse savoir de quel type est l'attribut et donc de prendre le bon getter.

Mais bon ce n'est pas le sujet....

tchize_ : quels avantages selon toi ? à part ce que Népomucène nous a exposé...

[Boojum]

Attention à bien lire l'article de codemonkey : il ne parle pas d'affecter directement les variables sans passer par un setter. Il dit qu'autant que possible, les objets devraient être immutables (on ne peut pas les modifier après leur création) et donc qu'on ne modifie pas les variables du tout ! C'est généralement une bonne pratique que de rendre immutable tout objet qui peut l'être, mais ce n'est pas le cas de tous.

Pöur en revenir au sujet : le principal avantage du getter/setter est de rendre l'implémentation invisible. Le champ peut être chargé paresseusement (à la première initialisation), la valeur peut être calculée plutôt que stockée, etc. Pour les accès externes, c'est AMHA indispensable sur tout projet de taille moyenne qui est amené à évoluer dans le temps. Le coût pour le mettre en place est négligeable (l'IDE le fait tout seul), et ça fait économiser énormément de temps lorsqu'on doit mettre en place l'un des éléments évoqués plus haut.

En interne dans la classe, je trouve ça assez lourd. J'aurais tendance à utiliser directement l'attribut. Si je modifie un jour la classe pour que le getter face un truc en plus (chargement paresseux par exemple), ça ne me coûtera pas grand chose de faire une passe rapide sur la classe pour vérifier les utilisations de l'attribut.

Ah, et synchronized sur les getters : surtout pas sans bonne raison ! Ça provoque des goulots d'étranglement dans le code, et c'est très rarement utile. Sur les setters, on peut avoir des cas où ça se justifie, mais honnêtement : écrire du code robuste et performant en multithread, ce n'est pas facile. Le plus simple est de considérer que tout objet qui n'est pas écrit spécifiquement pour être partagé entre différents threads ne doit pas l'être, donc pas la peine de s'embêter avec des synchronized.

[tchize_]

this -> uniquement en cas d'ambiguité ou de possible doute.

accès en interne au getter / setter -> ça a ses avantages, mais je trouve que ça alourdis le code. A noter qu'il y a une case à cocher pour utiliser ou non les getters / setters en appel interne