Bonjour, je n'ai pas compris l'utilité des mutateurs si au final c'est pour modifier la valeur comme on pourrait le faire sans mutateurs.

Quelqu'un pourrait m'eclairclir SVP? Merci.

Tu as tout à fait raison, c'est pourquoi il faut restreindre les setter au maximum pour préserver l'encapsulation.

Ils sont nécessaires dans certains cas:

-logique de validation, le setter vérifie par exemple que la nouvelle valeur n'est pas null.

-autre logique, logging par exemple, ou annotations avec un scope method.

-Reflexion, certains framework se basent sur ces méthodes pour connaitre le contenu d'un objet(d'ou la spécification bean).

Dans d'autre cas, mettre le champs en public(ou protected ou package) reviendrait au même résultat si un getter est associé au setter.

L'avantage d'un mutateur, c'est que tu peux contrôler si la valeur donnée à ton attribut est valide.

Après, admettons que tu n'aies pas besoin de vérifier la valeur donnée à ton attribut. C'est quand même mieux d'en faire un plutôt que de laisser ton attribut public parce que

• Ca ne coûte rien de le faire. Avec n'importe quel IDE digne de ce nom, ça se fait en un clic.
• Si un jour, tu décides que finalement, ton attribut doit finalement respecter certaines règles, tu auras juste le mutateur à modifier.

Je rajouterai que c'est un des principes de la POO : l'encapsulation

• Tu n'as pas à connaître la composition (les attributs), ni avoir accès à l'intérieur de la classe ;
• Tu passes toujours par l'interface de la classe (c'est à dire les méthodes) pour effectuer tes actions ou modifications.

-
Edité par Pinguet62 23 février 2014 à 19:29:58

Pinguet62 a écrit:

Je rajouterai que c'est un des principes de la POO : l'encapsulation

• Tu n'as pas à connaître la composition (les attributs), ni avoir accès à l'intérieur de la classe ;
• Tu passes toujours par l'interface de la classe (c'est à dire les méthodes) pour effectuer tes actions ou modifications.

-
Edité par Pinguet62 il y a 4 minutes

Justement, l'encapsulation en prend un coup avec les setter:

-tu modifies directement l'état interne de l'objet.

-tu passes des références qui peuvent être mutables et donc l'objet est modifiable depuis l'extérieur.

-tu exposes la composition de la classe.

Si c'est acceptable pour des classes de base, comme les beans(et encore c'est vraiment parce qu'il y a pas le choix), pour des classes nécessitant un controle plus strict c'est dangereux.

Il y a un problème avec les exemples qui servent, par fainéantise traditionnelle, à montrer les accesseurs et mutateurs.

Genre classe Point, avec deux coordonnées x et y , et des accesseurs getX/getY/setX/setY... C'est le cas (typique) où ce qu'on veut représenter, ce ne sont pas des objets, avec un état interne qui serait modifié/consulté par l'intermédaire de méthodes, mais des bonnes vieilles structures qui regroupent des champs auxquels on veut accéder librement. La représentation interne, raisonnablement, ne changera jamais.

En fait ce genre d'exemple ça permet bien à quelqu'un qui sait programmer de comprendre ce qu'est un accesseur (mais on pourrait aussi bien lui expliquer avec un Titi qui contient un Tata et un Toto), mais sur un débutant ça a un effet de bord désastreux, celui de lui faire croire qu'avoir des champs publics, c'est mal.  Et donc qu'il faut coller des accesseurs partout.

-
Edité par michelbillaud 23 février 2014 à 20:23:47

J'abonde dans le sens que les setters sont généralement une rupture d'encapsulation. On tend à les mettre quand on continue à penser en termes de données, et non en termes de services. Et dans une classe dont le service est d'agréger des données, la pertinence du setter est faible. Si l'objet fait un set_on_conditions, ou un set_and_notify, le verbe n'est plus set.

Bref des liens qui illustrent un peu tout ça:

* service ou données:
- http://fr.openclassrooms.com/forum/sujet/probleme-d-amitie-63712#message-6675973
-http://progdupeu.pl/forums/sujet/289/javascript-et-encapsulation#p5739

* Nommage du service réel:
- http://blog.emmanueldeloget.com/index.php?post/2006/09/14/12-la-guerre-des-accesseurs
-

* Le rapport aux invariants:
- http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and
- http://www.artima.com/intv/goldilocks3.html

* Autres liens en vrac:
- http://stackoverflow.com/questions/565095/are-getters-and-setters-poor-design
- http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html
- http://www.javaworld.com/article/2072302/core-java/more-on-getters-and-setters.html
- http://typicalprogrammer.com/doing-it-wrong-getters-and-setters/
- http://www.idinews.com/quasiClass.pdf
- http://www.developpez.net/forums/d1294290/c-cpp/cpp/bonnes-pratiques-convention-commenter-code-cpp/#post7052654