Info Setteurs / Getteurs

Version imprimable

12/02/2010, 12h39
Altal

Info Setteurs / Getteurs

Bonjour,
Est ce que quelqu'un pourrait juste me linker un tuto sur les Setteurs et les getteurs en C++ ou m'expliquer vite fais si ce n'est pas trop long svp? Je ne trouve pas sur le forum en tapant getteurs ou setteurs :s.

Merci à vous
12/02/2010, 13h57
3DArchi

Salut,
Tu ne trouves pas d'info sur les g/setter probablement parce que ça relève souvent d'une erreur de conception :mrgreen:
Une entrée de la F.A.Q. en parle : Que sont les accesseurs / mutateurs ?
Que cherches-tu à faire ?
12/02/2010, 14h03
Altal

Bonjour,
Je cherche à envoyer des données récupérées dans des Edit Control dans une variable qui elle se trouve dans une autre classe.
Merci pour cette réponse, je ne pensais pas que cela se nommait ainsi.
Bon à savoir :)
12/02/2010, 14h13
3DArchi

L'amitié avec le contrôleur ? F.A.Q. : Les amis brisent-ils l'encapsulation ?
12/02/2010, 14h40
Altal

Oula ^^.

Je ne suis qu'en BTS informatique (IRIS) en alternance et nous n'avons même pas encore vu ca mdr .

En fait je dois faire un projet en entreprise et ils m'ont conseillé d'utiliser des accesseurs / mutateurs pour faire ce que je voulais :s. Par contre ils sont malin ils ne m'ont pas expliqué ^^.
Je les ai vu en cours mais on n'a pas fait d'applications donc je suis surtout bloqué sur le coté "mise en pratique" :s.

L'idée (pour faire simple), dans une fenêtre MFC on demande à l'utilisateur de choisir/taper un chemin un/de fichier à convertir. Le chemin du fichier choisit est affiché dans un Edit Control et enregistré dans une variable (name_folder_in_csv) associée à ce Edit Control. Je dois ensuite placé le contenue de cette variable dans une variable (m_pDataFile) présente dans une classe de données que j'ai créer afin d'y avoir accès via une autre page.

J'ai bien lu les liens que vous m'avez mis mais je ne comprend pas s'il faut créer une fonction Accesseur et une fonction Mutateur dans la classe de donnée ou non afin de pouvoir par la suite y accéder depuis n'importe classe.

Merci pour votre patience et votre compréhension

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class ma_classe
{
CString& chaine()
{
   return ma_chaine;
}
CString const & chaine() const
{
   return ma_chaine;
}
 
private:
CString ma_chaine;
};
 
ma_classe mon_objet;
mon_objet.chaine() = ma_chaine_de_mon_edit;
ma_chaine_de_mon_edit = mon_objet.chaine();

Mais si tu optes pour ça, alors ma_chaine n'est plus un membre privé. Donc autant écrire :

Code:

1
2
3
4
5
6
7
8
9
class ma_classe
{
public :
CString ma_chaine;
};
 
ma_classe mon_objet;
mon_objet.ma_chaine = ma_chaine_de_mon_edit;
ma_chaine_de_mon_edit = mon_objet.ma_chaine;

Au moins, comme ça c'est clair.

12/02/2010, 14h52
Altal

Ha bha là j'ai compris :D.
Bien détaillé et tout, tout simplement nikel!
Et en plus ca fonctionne dans mon code^^.

Merci (beaucoup) Archi ^^

[Problème résolu]

Salut, et bienvenue sur le forum.

De manière générale, ainsi que l'a fait remarquer 3D, l'utilisation de getter (on parle, en français d' "accesseur") et de setter (on parle, en français de "mutateur") releve, effectivement, d'un problème de conception.

En effet, le concept même de l'orienté objet consiste, pour partie en tout cas, à envisager les objets sous l'angle des services que l'on attend d'eux, et non sous l'angle des données dont ils sont composés.

A titre d'exemple, on se doute qu'un réservoir permet de contenir une certaine quantité de carburant, et l'on pourrait donc envisager d'avoir les accesseurs getQuantité et getQuantiteMax et les mutateurs setQuantite et setQuantiteMax, mais ce qui nous intéresse principalement ce sont les comportement que l'on pourra observer quand... le réservoir sera fixé à la voiture.

A ce moment là, nous pourrons alors décider:

d'ajouter une certaine quantité de carburant (qui accepte d'ajouter la quantité indiquée si et seulement si la somme de la quantité actuelle et de la quantité à ajouter est inférieure ou égale à la quantité maximale admise)
de retirer une certaine quantité de carburant (à chaque fois qu'il y en a qui est envoyé au moteur)
d'interroger le réservoir sur son "état de remplissage" (nous obtenons alors un rapport entre la quantité maximale qu'il peut contenir et la quantité qu'il contient effectivement-
d'interroger le réservoir pour savoir s'il est rempli (qui nous donne vrai quand la quantité actuelle est égale à la quantité maximale)
d'interroger le réservoir pour savoir s'il est vide (qui nous donne vrai quand la quantité actuelle vaut 0)
d'interroger le réservoir pour savoir si nous sommes "sur réserve" (qui nous donne vrai quand la quantité actuelle passe en dessous d'un certain niveau)

On en arrive de ce fait à la conclusion que:
Le mutateur sur la quantité maximale n'a pas lieu d'être, étant donné que la quantité maximale ne sera jamais modifiée une fois l'objet construit: il s'agit d'une information intrinsèque au réservoir qui doit être, afin de respecter l'idiome RAII, définie au moment de la construction d'un réservoir.
Le mutateur sur la quantité actuelle n'a non plus lieu d'être étant donné que nous ne modifierons la quantité actuelle qu'au travers du comportement qui consiste à ... ajouter du carburant.
Les accesseurs sur la quantité maximale et sur la quantité actuelle deviennent "moins intéressants" du fait que l'on dispose d'un certain nombre de comportements dont les noms sont clairement explicites et qui rendent des services bien plus "spécialisés" qu'un simple accesseur

Autrement dit, les getXX et les setXXX que j'ai introduit au début ne servent à rien... et l'idiome YAGNI (You Ain't Gonna Need It) nous conseille... de ne pas les définir :D

De plus, il existe ce que l'on appelle la "loi demeter", que l'on essaye de respecter autant que faire se peut.

Cette loi nous dit que, si un objet de type A utilise en interne un objet de type B, et qu'un troisième objet de type C manipule l'objet de type A l'objet de type C ne devrait pas connaitre l'objet de type B manipulé par A.

Un peu de code te permettra de comprendre: les commentaires y aideront beaucoup :D
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 /* Soit la classe B */ class B { /* contenu de B */ }; /* et la classe A qui manipule la classe B */ class A { public: /* on pense en terme de comportement :D */ void doSomething() { /* on peut manipuler myB ici, en fonction du comportement * recherché */ } /* par contre, un mutateur ou un accesseur tel que classiquement * défini va à l'encontre de demeter, parce que A expose le type B */ B const & getB()const{return myB;} void setB(B const & b){myB=b;} private : B myB; }; /*Et la classe C qui utilise A */ class C { public: /* C doit déjà connaitre A pour cette fonction */ void someStuff(A const & a) { a.doSomething(); } /* mais, ici, il faut, en plus connaitre B :P */ void otherStuf(A const a) { B b=a.getB(); /* utilisation de b */ } };
En résumé, la "syntaxe" des mutateurs et accesseurs est, effectivement, facile à comprendre, mais, avant de s'y intéresser, la bonne question à se poser est, très clairement "en ai-je besoin :question:", et, bien souvent, il apparait que tu as en réalité souvent bien plus besoin de comportements clairement définis pour lesquels tu sais à l'avance ce qui sera fait et dans quelles conditions, que de "simples" accesseurs / mutateurs ;)

12/02/2010, 15h52
Altal

Tout simplement merci :)

Très bien détaillé/expliqué

Merci à l'équipe de développez.com

A bientôt ^^