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

[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

[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

[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.

[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

[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.

[JoeChip]

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

Oui, en effet. Pratiquement on devrait arriver à des formes comme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
new MainFrame(new MyMainParams())
    .addMenuBar(new MenuBar()
        .addMenu(new Menu ("Aide")
            .addLine(new MyAPropos())
            .addLine(new MyTableDesMatieres())
            [...]
        )
        [...]
    )
    [...]
    .start();

(Avec comme convention que où il n'y a pas "My" il s'agit de la classe standard, bien sûr en pratique faut pas forcément mettre "my"...).

On repousse alors tous les détails plus "bas", en on fait vraiment de l'objet, et non de l'impératif structuré en forme d'objets. De cette façon on ne se répète pas (en tout cas localement), et les sources ressemblent à l'appli, à chaque niveau, avec de plus en plus de détails, donc d'attributs et aussi de répétitions, quand on descend en niveau.

[Népomucène]

Il a écrit textuellement :

You should not use setters. Think about each setter you want to write, are they really necessary for your fields? Better create new copies of your objects if values change

Et là je ne vois pas bien où il veut en venir :
Ex : j'ai besoin d'une zone de saisie particulière et je crée un composant qui étend JtextField.
Pour placer une valeur par défaut j'utilise setText()
Ensuite l'utilisateur fait sa saisie et a donc modifié le texte
pour récupérer ce texte et le mettre dans le SGBD, j'utilise getText()

Pourquoi et comment veut-il que je fasse une copie de mon objet ?????

J'ai l'impression qu'on ne parle pas de la même chose.

[tchize_]

Dans l'absolu c'est bien ce qui se passe. Ce ne sont pas des nouveau JTextField qui sont créés mais des nouvelles String Bon c'est du chipo mais il n'a pas tout à faire tord. Pas mal d'objet qu'on code avec des getters /setters pourraient être plutot des objets immutable. Evidement, pas tous, mais on à la sale tendance à très peu utiliser final dans des classes qui pourtant ne sont que des coquilles autour d'une ensemble de donneés immutables

Tiens par exemple, combien pensent en programmant leur setters "si je fais ça, mon objet ne pourra jamais être une clé dans une Map"

[JoeChip]

Ouais, mettre systématiquement des getters/setters, c'est un peu encombrer d'office le code tout en renonçant partiellement à réfléchir. Il faut aussi ne pas oublier aussi qu'on peut vouloir rigidifier le code par endroits, ou bien vouloir des performances d'accès à la donnée qui nécessitent d'éviter les cascades de get/set.

[deathness]

Dans l'absolu c'est bien ce qui se passe. Ce ne sont pas des nouveau JTextField qui sont créés mais des nouvelles String Bon c'est du chipo mais il n'a pas tout à faire tord. Pas mal d'objet qu'on code avec des getters /setters pourraient être plutot des objets immutable. Evidement, pas tous, mais on à la sale tendance à très peu utiliser final dans des classes qui pourtant ne sont que des coquilles autour d'une ensemble de donneés immutables

Tiens par exemple, combien pensent en programmant leur setters "si je fais ça, mon objet ne pourra jamais être une clé dans une Map"

Ceci dit eclipse peut mettre de lui même un final a toutes les variables locale ou non, paramètres et autres à chaque fois que c'est pertinent simplement en lui demandant de faire une mise en forme de notre code (de mémoire, Source->Clean up).
C'est très pratique.

[Boojum]

Ex : j'ai besoin d'une zone de saisie particulière et je crée un composant qui étend JtextField.
Pour placer une valeur par défaut j'utilise setText()
Ensuite l'utilisateur fait sa saisie et a donc modifié le texte
pour récupérer ce texte et le mettre dans le SGBD, j'utilise getText()

Pourquoi et comment veut-il que je fasse une copie de mon objet ?????

J'ai l'impression qu'on ne parle pas de la même chose.

Tu ne peux clairement pas faire ça n'importe où. L'idée est de rendre immutables les objets qui peuvent l'être. Les éléments de l'IHM, ou dans une application de gestion les objets du domaine qui vont être modifiés par l'utilisateur, vont rester mutables. Par contre, tes éléments techniques, tes types de données... vont être aussi immutables que possible.

Exemple : dans une application sur laquelle j'ai bossé, on a dû introduire le concept de "période" (un mois ou un trimestre donné). J'ai donc créé la classe Periode avec toutes les méthodes nécessaires. Cette classe, je l'ai rendue immutable : si tu veux changer la période, tu en créés une nouvelle. Les opérations qui permettent de récupérer la suivante, la précédente, d'avancer de X mois, etc., renvoient des nouvelles valeurs mais ne modifient pas l'instance.

C'est exactement la logique suivie par Java lui-même sur des classes comme BigDecimal ou String. Une fois créé, tu n'y touches plus. C'est aussi un des principes fondamentaux de la programmation fonctionnelle (avec des langages comme Lisp ou Haskell, ou plus souple Ruby ou Scala).

Il faut aussi ne pas oublier aussi qu'on peut vouloir rigidifier le code par endroits, ou bien vouloir des performances d'accès à la donnée qui nécessitent d'éviter les cascades de get/set.

Honnêtement, le gain de performance obtenu en accédant directement à la donnée plutôt qu'en passant par un get est très très rarement notable dans une application non triviale. Quand à côté tu as des accès BDD, des accès réseaux, etc., c'est complètement négligeable.

[JoeChip]

le gain de performance obtenu en accédant directement à la donnée plutôt qu'en passant par un get est très très rarement notable dans une application non triviale. Quand à côté tu as des accès BDD, des accès réseaux, etc., c'est complètement négligeable.

Complètement d'accord en ce qui concerne les applications "habituelles", mais bon il peut arriver qu'on gratte tout ce qu'on peut pour améliorer les perfs, je voulais juste donner des exemples où il faut réfléchir à la pertinence des getters/setters... Il doit y en avoir d'autre, meilleurs.