Discussion :

[VanLoc]

Bonjour,

Voila je suis nouveau sur le forum, j'ai épluché un peu le site à la recherche d'infos sur ce sujet, j'ai obtenu des infos intéressantes mais des questions subsistes.

Voici un petit exemple qui illustre mes interrogations :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
class CRoue
{
private:
    float m_fDiametre;
public:
    const float & GetDiametre() const;
    void SetDiametre(cont float & fDiametre);
}
 
class CVoiture
{
private:
    CRoue m_roue;
 
public:
    const CRoue & GetRoue() const;
}

peut on remplacer :

Code :

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

const float & GetRoue() const;

par :

Code :

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

float & GetRoue();

ainsi on peut appliquer le mutateur SetDiametre() directement :

Code :

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

1
2
3
4
5
6
 
void main()
{
    CVoiture voiture;
    voiture.GetRoue().SetDiametre(500.0);
}

Ou faut il garder :

Code :

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

const float & GetRoue() const;

et créer le mutateur du diamètre de la roue directement dans la classe CVoiture? :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
class CVoiture
{
private:
    CRoue m_roue;
 
public:
    const CRoue & GetRoue() const;
    void SetDiametreRoue(const float & fDiametre);
}
 
void CVoiture::SetDiametreRoue(const float & fDiametre)
{
    this->m_roue.SetDiametre(fDiametre);
}
 
void main()
{
    CVoiture voiture;
    voiture.SetDiametreRoue(500.0);
}

Un accesseur n'est pas censé modifier la donnée qu'il retourne mais peut il retourner un pointeur sur cette donnée pour que celle ci soit modifiée?
Sinon, doit on développer des mutateurs dans chaque classe contenant l'objet à modifier (ex : SetDiametre() et SetDiametreRoue() un mutateur par classe) ? Ceci alourdit le code, y'a t'il une autre solution?

Voila, j'espère avoir été clair
Merci d'avance

[r0d]

Bonjour,

pour ma part, je pense que c'est une question presque philosophique, et au moins sémantique. Je m'explique:
Si une fonction porte le nom GetX(), cela signifie: donne-moi la valeur de la variable x, étant sous-entendu que c'est seulement pour connaitre cette variable, et non dans le but de la modifier. En effet, si on veut modifier cette variable, on utilsera plutot un modificateur (setter) du style: SetX( float nouvelle_valeur );

Enfin, si tu souhaites que ta variable membre x puisse être modifiée par "tout le monde", alors pourquoi ne pas directement la mettre en public? Certes cela rompt l'encapsulation, mais ce n'est pas forcément mal, et puis de toutes façons, si tu as un accesseur qui renvoie une référence non constante vers cet objet, cela rompt également l'encapsulation.

C'est mon point de vue. Moi je n'hésite plus à déclarer en public des variables membre lorsqu'il n'y a pas de raison pour qu'elles ne le soit pas.

[Oussapik]

Je pense également qu'il s'agit ici plus d'une question de sémantique.

Ce qu'il faut se poser comme question, c'est "est-ce que ma classe englobante doit avoir connaissance du paramètre de la classe englober ?" J'entend par là que plusieurs méthodes sont à mon avis toutes aussi valables les unes que les autres suivant le contexte.

Dans ton cas, je trouve que d'ajouter une méthode setDiametreRoue dans CVoiture est une idée tout à fait correcte. Elle va juste englober un appel à m_roue.SetDiametre(...).

Par contre, enlever le const sur un getter est, de mon point de vue, une pratique à éviter. De façon général, si on demande à obtenir une valeur, on ne demande pas à la modifier.

[VanLoc]

Tout d'abord merci

Vos réponses m'éclairent un peu sur le sujet, mais je ne peut m'empêcher de penser que d'un côté, si je fait un mutateur sur chaque classe englobante on va atteindre un nombre hallucinant de méthodes dans la classe qui englobe toutes les autres.
Et d'un autre côté, je me dis que rompre l'encapsulation n'est pas une bonne chose.
Un compromis entre les deux me pousserais à respecter l'utilisation d'accesseurs et de mutateurs pour les variables membres de types communs, int, float, bool... et mettre les variables membres étant des classes complexes en public.

J'ai bien retenu la question à se poser :

est-ce que ma classe englobante doit avoir connaissance du paramètre de la classe englober ?

La plus part du temps dans mon cas c'est oui, c'est donc peut être dû à un mauvais découpage des classes dès le début de la conception .

En tout cas merci pour vos réponses

[gl]

Vos réponses m'éclairent un peu sur le sujet, mais je ne peut m'empêcher de penser que d'un côté, si je fait un mutateur sur chaque classe englobante on va atteindre un nombre hallucinant de méthodes dans la classe qui englobe toutes les autres.
Et d'un autre côté, je me dis que rompre l'encapsulation n'est pas une bonne chose.

En mettant des accesseurs/mutateurs sur tous les membres de ta classe (surtout s'ils sont triviaux), tu romps déjà l'encapsulation. Conceptuellement,que tu puisses accéder à tous les membres de ta classe car ils sont public ou car il existe un mutateur sur chacun d'entre eux cela ne change pas grand chose.

Raisonne sur les services qu'offrent la classe plutôt que sur les données qui la composent.

[koala01]

Salut,

Je rejoins gl dans mon approche...

Normalement, les membres d'une classe devraient surtout être utilisés pour permettre à la classe de rendre les services que l'on attend d'elle...

Dans le cas présent, il faut te poser la question de savoir quelle service tu attend que ta classe Roue puisse te rendre grâce à son membre diamètre.

Une chose est sure, c'est que si tu peux effectivement attendre qu'elle soit en mesure de répondre à la question "quel est ton diamètre", il n'y a, a priori, aucune raison de pouvoir le modifier...

Si tu change le diamètre d'une roue, tu obtiens, purement et simplement, une autre roue