Discussion :

[khadi8]

Salut !
J'ai une question bête peut être mais que je comprends toujours pas, voila c'est a propos des getter et setter, j'arrive pas a voir leurs utilité, c'est pour rendre les attributs privé OK, mais pourquoi le faire tant que on pourra quand même accéder a cet attribut avec ces méthodes la, en bref j'arrive pas a voir leurs utilités.
Merci

[XxArchangexX]

Bonsoir,

Pour ma part je les vois comme des clefs pour accéder à une classe non apparenté à celle-ci. Prend ta classe comme ton compte en banque ta variable c'est ton argent, ta carte bleu c'est ton getter, si ta variable est publique tout le monde y a accès. Sa permet d'autoriser que la lecture ou que l'écriture.

Sa oblige à connaitre la classe pour utiliser la variable c'est un principe de développement après les règles sont la pour être violées ^_^°. Mais un standard permet à la personne qui passe derrière toi de s'y retrouver un peu. Le nombre de stage en informatique pour les DUT qui sont dans la réécriture propre de site web ou d'application, quand j'ai fais ce stage j'ai été surpris.

[thelvin]

Ben, les getters et les setters, ce sont des méthodes. Les variables, ce sont des attributs. Une méthode peut être redéfinie, un attribut ne le peut pas. L'un est plus souple que l'autre.
Même sans parler de redéfinir, un getter ou un setter permet d'associer une action chaque fois qu'il est appelé. Ce n'est pas le cas de la lecture ou écriture d'un attribut.
On dit souvent qu'un getter ou un setter ne devrait pas faire autre que juste lire ou modifier l'attribut. C'est un peu vrai, il vaut mieux pas, mais si besoin c'est en tout cas possible. Sans getter ou sans setter, ce n'est pas possible.

Par ailleurs, ça a pris un côté cargo cult. À présent, tout le monde utilise les getters et setters. Et donc, tout le monde considère que tout le monde le fait. Les outils se basent là-dessus et pas sur autre chose. Mettre des getters et setters ne coûte rien. Donc ne pas en mettre, n'a aucun avantage et ne peut attirer que des ennuis.

[deathness]

En mettre peut avoir un avantage, c'est de pouvoir rapidement tracer toutes les lectures-écritures d'une variable.
Dans un contexte ou tu as besoin de traces, cela te facilite bien la vie.

[professeur shadoko]

C'est une bonne question car il y a confusion totale au niveau des "conventions de beans".
Un bon exemple vaut mieux qu'un long discours:

Code :

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

1
2
3
4
5
6
7
 
public class CompteEnBanque {
    private Valeur découvertAutorisé ;
    private Valeur solde ;
    private List<Operation> historique ;
   // autres champs
}

Ici on va distinguer les manipulations de ces instances lors d'opérations "normales" (c.a.d lors du fonctionnement d'un code "métier") et lors d'opérations de reconstitution (depuis une base de données par exemple).

En opération métier:
- on peut avoir un get et un set sur découvertAutorisé
- on peut avoir un get sur solde mais pas un set ! celà violerait l'encapsulation! (seules les opérations "dépot" et "retrait" locales au code modifient le solde).
- idem sur historique et de plus le get est très particulier car il doit rendre une liste non modifiable!

en opération de reconstitution on peut avoir les "set" manquants (mais ils doivent être non public!)
mettre partout des set et des get sans analyser leur rôle est une grave erreur (malheureusement beaucoup de frameworks ont mal digéré les raisons d'être des conventions de beans et poussent au crime !)

[thelvin]

(malheureusement beaucoup de frameworks ont mal digéré les raisons d'être des conventions de beans et poussent au crime !)

Dans le cas présent, c'est surtout que de la logique métier n'a rien à faire dans un bean de ce sens-là du terme. Ils appellent "bean" tout ce qui n'est qu'une manière de représenter des données, totalement mutable ou totalement immutable. Ce qui est entre les deux, ça contient de la logique et n'est pas un bean à leur sens du terme.