Gestion des getter et setter

**raimus88** · 07/11/2009, 23h37

Bonjour

J'ai une application graphique avec pas mal de textfield textarea etc...J'ai donc pas mal de getter et de setter. Je me demandais si il y avait une gestion possible pour l'organisation des getter et setter. C'est à dire peu t'on les placer dans une autre classe car cela alourdi la visibilité du code.

Merci pour les informations

**slim_java** · 08/11/2009, 00h32

Envoyé par raimus88

C'est à dire peu t'on les placer dans une autre classe

ça na pas de sens, sinon tu peut ne pas utiliser des getter et des setter si t'as pas besoin de protéger l'accès aux attribut de tes classes dans le cas ou ton code sera pas utiliser par d'autres

**Alain Defrance** · 09/11/2009, 09h16

Bonjour,

Pour la visibilité c'est exact, mais les bon editeurs permettent de hider getter/setter/constructors.

**OButterlin** · 09/11/2009, 09h34

Envoyé par Alain Defrance

Bonjour,

Pour la visibilité c'est exact, mais les bon editeurs permettent de hider getter/setter/constructors.

Juste pour info, avec Eclipse, ça se ferait où ? (je n'ai pas trouvé l'option

)

(tu vas me dire, j'avais dit : "les bons éditeurs..."

)

**Alain Defrance** · 09/11/2009, 09h57

Envoyé par OButterlin

(tu vas me dire, j'avais dit : "les bons éditeurs..."

)

Tu t'es répondu tout seul :p

**thelvin** · 09/11/2009, 10h21

Soit dit en passant, on *peut* placer les getter/setter dans une autre classe : une classe imbriquée...

Mais ça oblige à appeler d'abord une instance de cette autre classe avant le getter/setter, ce qui n'aide pas à la visibilité. Et puis, les getter et setter sont toujours là, juste regroupés dans une classe imbriquée.

Rien n'empêche de regrouper les getter/setter à la fin de la classe : ça marche exactement comme s'ils étaient dispersés, sauf que ça ne gêne pas la lisibilité.

**raimus88** · 09/11/2009, 10h26

Qu'est ce que tu apelles le faites de pouvoir hider les getter et setter dans un IDE. J'utilise Netbeans, cela va se trouver dans les options....?

Merci pour les infos

Invité · 09/11/2009, 10h48

salut,

Si tu as netBeans normalement dans la marge a gauche du code tu as des petits "-" sur les quelles tu peux cliquer et qui te permettent de "cacher" toute la partie correspondante.
Tu peux le faire avec une méthode, les imports ou même avec une classe complète.
Tu peux faire pareil avec les getter et setter.

Pour générer tous les getter et setter proprement tu peux aussi cliquer à la fin de ta classe et faire un clique droit puis "insert code" (version anglaise)
et la choisir "getter and setter".
Il va te proposer toutes les variables de ta classe que tu peux générer, tu n'as plus qu'à choisir.

En espérant que ça t'a aidé.

**OButterlin** · 09/11/2009, 11h03

Envoyé par raimus88

Qu'est ce que tu apelles le faites de pouvoir hider les getter et setter dans un IDE. J'utilise Netbeans, cela va se trouver dans les options....?

Ben non, il avait dit "les bons éditeurs"

**Alain Defrance** · 09/11/2009, 11h17

Envoyé par OButterlin

Ben non, il avait dit "les bons éditeurs"

Sisi netbeans sait le faire nativement, même si c'est pas ce que j'utilise :p

Invité · 12/11/2009, 06h08

En meme temps, si un bon editeur est un editeur permettant de replier les méthodes... Il y a un bon paquet de bons editeurs sur le marche

Mais on s'éloigne...Alain Defrance, tu parlais de simplement replier les méthodes ou vraiment de faire en sorte qu'elles n'apparaissent pas du tout ?? Car afficher un getter ou setter replié ou déplié, sachant qu'ils font la plupart du temps une unique ligne de code, cela ne fait pas une différence extraordinaire...

Sur ce point la je regrette l'absence de regions comme en C#, ou il suffirait de créer une region "Constructeurs" et de la replier pour tout cachedr

**michel.di** · 12/11/2009, 07h44

bonjour,

vous êtes plusieurs à dire que Eclipse et Netbeans ne sont pas de bons éditeurs, que vaut-il mieux utiliser afin de facilité cette gestion des getters/setters et autres points en général?

**OButterlin** · 12/11/2009, 08h49

Envoyé par michel.di

bonjour,

vous êtes plusieurs à dire que Eclipse et Netbeans ne sont pas de bons éditeurs, que vaut-il mieux utiliser afin de facilité cette gestion des getters/setters et autres points en général?

Eclipse ET Netbeans sont d'excellents EDI, il n'y a aucun doute.
Certains préfère Eclipse, les autres Netbeans, c'est plus une question d'habitude que de réel avantage de l'un par rapport à l'autre.
Et il est vrai que pouvoir masquer les getter/setter n'est pas vraiment une fonctionnalité super intéressante...

**Alain Defrance** · 12/11/2009, 09h01

Envoyé par PierreAd

Car afficher un getter ou setter replié ou déplié, sachant qu'ils font la plupart du temps une unique ligne de code, cela ne fait pas une différence extraordinaire...

Si on l'écrit à la bien ca fait 3 lignes + 1 au moins de commentaire pour passer au checkstyle. Pour les constructeurs c'est encore plus parlant si on initialise 3-4 valeurs.

Envoyé par PierreAd

Sur ce point la je regrette l'absence de regions comme en C#, ou il suffirait de créer une region "Constructeurs" et de la replier pour tout cachedr

En ce qui me concerne je ne regrette rien du tout. Savoir que dans le même fichier j'ai toute ma classe et qu'il ne reste pas de bouts à droite ou à gauche c'est à mon sens pas négligeable.

Envoyé par michel.di

vous êtes plusieurs à dire que Eclipse et Netbeans ne sont pas de bons éditeurs, que vaut-il mieux utiliser afin de facilité cette gestion des getters/setters et autres points en général?

Pour ma part je lance surtout de gros trolls. Un éditeur c'est bien souvent une question d'habitude. Pour ma part j'utilise IntelliJ pour pas mal de raisons qui me tiennent à coeur comme par exemple sa réactivité, sa gestion des frameworks, sa capacité à faire des relations entre des ressources, son support pour d'autres langages basés sur la JVM (Scala, Groovy) et bien plus mais je ne vais tout de même pas faire son éloge (ah c'est déjà fait ?

). Et puis PierreAd va nous crier parce qu'on s'éloigne encore plus du sujet

Invité · 12/11/2009, 23h26

Envoyé par Alain Defrance

Si on l'écrit à la bien ca fait 3 lignes + 1 au moins de commentaire pour passer au checkstyle. Pour les constructeurs c'est encore plus parlant si on initialise 3-4 valeurs.

Checkstyle ? Je connaissais pas... est-ce très couramment utilisé, j'avoue que c'est sans doute une des premières fois que j'en entends parler... Pour les setters/getters, je voulais dire une ligne dans le bloc de la méthode, mais effectivement 3 ou 4 lignes selon la façon dont tu formates ton code...

Envoyé par Alain Defrance

En ce qui me concerne je ne regrette rien du tout. Savoir que dans le même fichier j'ai toute ma classe et qu'il ne reste pas de bouts à droite ou à gauche c'est à mon sens pas négligeable.

Les regions en C# ne remettent pas du tout ça en cause. En fait il te suffit dans ton fichier de placer quelque part la directive "#region nomRegion" et un peu plus loin "#endregion", et cela te permet de replier toute cette région du code en gardant affiché le nom de la région en question, tout simplement. Toute ta classe demeure dans ton fichier si tu le souhaites

Envoyé par Alain Defrance

Et puis PierreAd va nous crier parce qu'on s'éloigne encore plus du sujet

Je fais ça moi ??

**OButterlin** · 13/11/2009, 08h29

Envoyé par PierreAd

Les regions en C# ne remettent pas du tout ça en cause. En fait il te suffit dans ton fichier de placer quelque part la directive "#region nomRegion" et un peu plus loin "#endregion", et cela te permet de replier toute cette région du code en gardant affiché le nom de la région en question, tout simplement. Toute ta classe demeure dans ton fichier si tu le souhaites

C'est vrai que le principe est plutôt sympa, ça ne devrait pas être très compliqué à mettre en oeuvre non plus, mais il faut tout de même que la directive soit prévue au niveau langage...

Pour revenir au sujet initial, il est vrai que dans 99% des cas (je suppose) les getter/setter n'ont rien de particulier, mais quelques fois, ils ont une logique propre... Ne pas les afficher masque cette logique...
Bref, il n'y a pas de règle pour décider s'il faut ou non les afficher, l'idéal serait d'avoir cette notion de région pour pouvoir les plier en 1x, à la demande.

**Rei Ichido** · 13/11/2009, 10h16

Envoyé par PierreAd

Checkstyle ? Je connaissais pas... est-ce très couramment utilisé, j'avoue que c'est sans doute une des premières fois que j'en entends parler... Pour les setters/getters, je voulais dire une ligne dans le bloc de la méthode, mais effectivement 3 ou 4 lignes selon la façon dont tu formates ton code...

Très couramment, je ne sais pas, mais moi ça m'arrive souvent de devoir l'utiliser dans mes projets (demande du client comme gage de qualité du code) ^^'

Envoyé par OButterlin

Pour revenir au sujet initial, il est vrai que dans 99% des cas (je suppose) les getter/setter n'ont rien de particulier, mais quelques fois, ils ont une logique propre... Ne pas les afficher masque cette logique...
Bref, il n'y a pas de règle pour décider s'il faut ou non les afficher, l'idéal serait d'avoir cette notion de région pour pouvoir les plier en 1x, à la demande.

Personnellement je fais toujours un effort de formatage de la classe, en mettant les getters / setters simples tout à la fin, ceux "avancés" juste avant, etc. C'est pas repliable sous Eclipse, mais ça reste suffisament propre à mon goût pour être lisible et ne pas gêner la lecture.

**Alain Defrance** · 13/11/2009, 11h11

Envoyé par PierreAd

Checkstyle ? Je connaissais pas... est-ce très couramment utilisé, j'avoue que c'est sans doute une des premières fois que j'en entends parler...

Oui c'est très répandu, beaucoup de boites qui mettent l'accent sur l'aspect qualitatif du code l'utilisent. Maven peut également générer le rapport durant le cycle de vie de l'application. Checkstyle fait partie des petites bêtes qui passent leur temps à nous embêter (comme cobertura) qui nous oblige à avoir un code impecable sous peine de se prendre un retour de bâton. Malheureusement quand on vend un projet à une entreprise en annoncant une converture de 90 % du code et/ou avec un respect des stadards il faut pouvoir le démontrer.

Envoyé par PierreAd

Pour les setters/getters, je voulais dire une ligne dans le bloc de la méthode, mais effectivement 3 ou 4 lignes selon la façon dont tu formates ton code...

Là on retombe encore sur des stadards.

Envoyé par PierreAd

Les regions en C# ne remettent pas du tout ça en cause. En fait il te suffit dans ton fichier de placer quelque part la directive "#region nomRegion" et un peu plus loin "#endregion", et cela te permet de replier toute cette région du code en gardant affiché le nom de la région en question, tout simplement. Toute ta classe demeure dans ton fichier si tu le souhaites

Au final t'es obligé de dire à ton éditeur comment il doit lire ton code. On peut pas se permettre ça en java ... Donc au final si l'éditeur sait le faire lui même c'est mieux non ?

**michel.di** · 13/11/2009, 11h16

Ouvrons une nouvelle discussion!

Invité · 15/11/2009, 23h20

Envoyé par Alain Defrance

Au final t'es obligé de dire à ton éditeur comment il doit lire ton code. On peut pas se permettre ça en java ... Donc au final si l'éditeur sait le faire lui même c'est mieux non ?

Hum oui bien sur, mais ceci dit, je ne vois pas vraiment pourquoi on ne pourrait pas se permettre ça en java ?

Pour Checkstyle je me renseignerai, je connaissais Cobertura mais jamais utilisé Checkstyle, ça m'intéresse, merci