Discussion :

[Samaie]

Bonsoir je fais de la programmation en c++ et j'aimerais savoir quel est le but de definir des membres privés dans une classe
On me repond toujours que c'est pour proteger tes membres .........
Mais en faisant appel a un mutateur ces meme membres pourront etre changés
Si quelqu'un pourrait bien m'expliquer les raisons
Merci

[sam_dev]

Ceci permet d'avoir plus de contrôle sur la modification.
Si tu laisses l'attribut public, n'importe quelle méthode d'une autre classe
pourra modifier l'attribut d'une façon qui pourrait ne pas te plaire.

Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class Eleve{
private :    
    int moyenne;
public : 
    void fixe_moyenne(int m){
        if(m>20 || m<0){
             cout << "Moyenne inadéquate" << endl;
        }else{
            moyenne = m;
        }
    };
}

Ainsi, tu l'utilisateur ne pourra fixer une moyenne en dehors de [0,20].

[Mat007]

Salut,

Mais en faisant appel a un mutateur ces meme membres pourront etre changés

C'est pour ça qu'on est supposé mettre le moins de mutateurs possibles (certains dont je suis diront même de ne jamais en mettre).

MAT.

[Samaie]

alors ds ce cas la ou ne pourra pas changer du tout nos membres privés??

[Luc Hermitte]

Si au travers de fonctions dédiées, qui incidemment altèreront l'état interne de l'objet. Mais ça, c'est leur problème à elles. Pas celui des clients.

[Davidbrcz]

On encapsule un comportement, pas des propriétés.

De ce fait, dans une bonne architecture objet les accesseurs,mutateurs devrait être interdit (suis-je trop extrémiste ?) ou tou du moins limité au possible.

Un bon article la dessus :
http://blog.emmanueldeloget.com/inde...-encapsulation

[koala01]

Salut,

Le gros problème, quand tu laisse les membres publics, c'est que n'importe qui peut décider de les modifier n'importe où.

Si, pour une raison ou une autre, tu décide de "réorganiser" tes membres (par exemple, en remplaçant les trois valeurs "séparées" représentant les coordonnées X, Y et Z d'un point trois dimensions en un tableau contenant les trois valeurs), tu devra parcourir l'ensemble de ton code (ou du moins de toutes les fonctions qui utilisent ta classe) pour t'assurer de répercuter la modification partout, et cela peut rapidement devenir ingérable.

Si tu rend les membres privés, et que tu y adjoint des mutateurs/accesseurs, le seul moyen de récupérer la valeur (ou de la modifier) passe par... ces derniers

Si, donc tu décide, pour une raison ou une autre, de réorganiser la manière dont les membres seront maintenus en mémoire, tu sera sur que la seule chose à laquelle il te faudra veiller sera... d'adapter le comportement des mutateurs/accesseurs, tout le reste du code ne subissant absolument aucune contrainte due au changement

De la même manière, si tu veux modifier le comportement des mutateurs/accesseurs (par exemple en rajoutant un test de cohérence quelconque), tu peux parfaitement apporter les modifications de manière tout à fait transparente pour l'utilisateur de ta classe.

Au final, tu gagne, en tant que concepteur de la classe, en liberté de mouvement (comprend: en facilité de modification au sein de la classe), et en tant qu'utilisateur de la classe en pérennité de ton code et en compatibilité entre versions différentes.

Bref, tu es gagnant sur tous les tableaux

C'est la raison pour laquelle, bien qu'il soit toujours conseillé de s'interroger sur l'utilité d'avoir un mutateur ou un accesseur, il est toujours plus sage de préférer une visibilité restrictive sur les différents membres

Le tout se faisant dans un seul et unique but: t'inciter à considérer ta classe comme un objet capable de rendre certains services en émettant ou en réagissant à des messages, et non plus comme la somme de l'ensemble de ses données.

Encore une fois, on se rend compte que la classe représente au final bien plus que la somme de ses composants