détail sur un principe de la POO

Bonjour,

On me soutiens que ce code:

Code:

---

1 2 3 4 5 6 7 8

class MaClass { private: int MaValeur; public: int get_MaValeur (); void set_MaValeur (int); };

---

est mieux que celui-ci:

Code:

---

1 2 3 4 5

class MaClass { public: int MaValeur; };

---

moi, je ne comprend pas pourquoi, si on a un champs auquel on peux accéder sans restriction, pourquoi ne pas le mettre en public??
Ai-je tord?

Mathieu.

A la rigueur protected peut être meilleur sinon ca dépend de ce qu'on veut faire mais tout mettre en public c'est clair on perds le principe de l'encapsulation. Maintenant dans ce cas ca évite d'ecrire un accesseur/mutator pour chaque donnée donc...

salut,
je te conseille de jeter un coup d'oeil ici:
http://c.developpez.com/faq/cpp/?pag...SSE_accesseurs
http://c.developpez.com/faq/cpp/?page=OO#CLASS_Get_Set

Cela te donnera quelques éléments de réponses.
@+

L'utilisation de getters et setters sont la pour securiser l'acces a ta/tes donnee(s).

Il faut je pense reflechir en reutilisation de ton code (c'est la l'interet de POO), celui qui appelera ta classe, ne sera pas forcement faire dans son code les verifications sur la variable saisie par l'utilisateur, ou sur le resultat d'un calcul: exemple

Tu invites ton utilisateur a saisir un chiffre qui sera le diviseur d'une operation, dans ton code tu pensera peut etre a verifier si la valeur est differente de 0 mais pas ton successeur , et donc plantage probable (Je sais pas si c'est vraiment explicite mais bon...)

Donc de maniere generale, eviter de laisser des variables de classe accessibles directement.

En esperant que cela t'eclaire un peu

rikau2

Dire que c'est mieux ou non, sans contexte, ça n'a pas beaucoup de sens.

Moi par exemple, selon le contexte, j'utilise l'une ou l'autre forme :

Code:

---

1 2 3 4 5 6 7

class Point { public :   int x; int y; };

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Sound { public :   int GetVolume() const; void SetVolume(int);   private :   int Volume; };

---

L'important c'est :
- De ne pas limiter l'évolution du code en donnant un accès publique à une variable qui va peut-être nécessiter des vérifications, des calculs, ou bien carrément ne plus exister directement en tant que donnée membre. Dans ce cas il faut prévoir les accesseurs même si l'on donne un accès en lecture et en écriture.
- De ne pas rendre le code inutilement verbeux avec des accesseurs lorsque ça ne sert vraiment à rien, par exemple dans les classes mathématiques.

moi ca dépend, après c'est en fonction des utilisateurs. Je connais mon code par coeur, donc j'utilise pas beaucoups de getters et de mutators... et quasiment jamais de private ^^.

En fait, en ce moment, le seul truc pour lesquels je l'utilise:

Citation:

---

C'est un projet où il y a une classe mère qui gère une liste chainée de classes filles. Chaque classe fille a une ID unique attribuée lors de sa création.

Le fonctionnement des classes mères peut dépendre de cette ID, et donc je la met en protected.

Donc l'utilisateur doit faire:

fille->getID();

au lieu de

fille->ID

et il ne peut jamais faire fille->setID();

---

Donc les getters et mutators sont souhaitables lorsque ce sont des données sensibles, manipulables uniquement par des membres de la classe ou dont la modification pourrait tout chambouler.

Sinon c'est une vraie perte de temps!

Edit: post croisé avec laurent

donc c'est bien ce que je pensai, par exemple, le champs 'age' d'une classe 'Personne' sera privé parce qu'on peux seulement l'incrémenter avec la méthode 'anniversaire'
alors que si la méthode set_xyz est seulement

Code:

---

1 2 3 4

void set_xyz (T i) { xyz = i; }

---

ce n'est pas forcément nécessaire de mettre xyz en privé.

En effet, bien définir l'action souhaitée sur chaque element de ta classe, et la definition de set & get se fera toute seule...

Bon prog

rikau2

Salut,

Dire que c'est mieux, c'est excessif, et tres dépendant de la classe que tu crées.

Comme Laurent l'a fait remarquer, ce qui importe, c'est de ne pas limiter l'évolution probable de ta classe.

Ou du moins, de s'assurer que, si un jour tu décides de modifier ta classe - remplacer x, y, et z par un T[3] ou par un vector<T>, par exemple - que tu ne te trouves pas devant l'obligation... de modifier le code partout ou x, y, ou z est utilisé.

Rien ne t'empeche, d'ailleurs (à part peut etre le souhait d'utiliser les templates) d'envisager carrément l'utilisation d'une structure plutot que celle d'une classe si, tout bien réfléchi, tu estime que la représentation en mémoire du(des) membre(s) ne sera jamais modifiée, et que tu veux un acces en lecture écriture...

Je te rappelle que,

Code:

---

1 2 3 4 5 6 7

class MonType { public: MonType(int i); ~MonType(); int i; };

---

et

Code:

---

1 2 3 4 5 6

struct MonType { MonType(int i); ~MonType(); int i; };

---

sont tout à fait équivalents ;)

Les questions du genre de

Citation:

---

serai-je le seul à utiliser la classe :question:

---

(le "je" pouvant etre considéré comme "ma petite équipe et moi meme"), ou, au contraire comme

Citation:

---

Ma classe sera-t-elle susceptible d'etre directement utilisée par quelqu'un d'autre que l'équipe -parce qu'il s'agit d'une bibliotheque que l'on fournira à plein de monde

---

sont déjà de nature à répondre en partie à la question de savoir s'il est préférable de maitriser l'acces direct aux membres ou non...

Si, parce que tu sais tres bien comment s'articulera ton application, tu sais pertinemment que l'acces à un membre d'une classe sera, quoi qu'il advienne, limité à une seule (allez, à la limite, à deux) fonction(s) externe(s) à la classe, ma foi, "pourquoi ne pas mettre le membre en public" :question:... Meme si tu décides un jour de modifier la manière dont le membre est représenté en mémoire, les modifications à apporter au code resteront minimes et clairement prédéfinies...

Si, par contre, tu sais que ta classe va "être mangée à toutes les sauces", que non seulement toi et ton équipe allez accéder aux membres de la classe dans une foule de fonctions, mais que, pourquoi pas, des gens extérieurs à l'équipe sont aussi susceptibles d'accéder aux membre de la classe... alors, là, il y a réellement danger à laisser les membres en visibilité publique...

Pour conclure, j'aurais tendance à rappeler qu'aucune solution n'est ni bonne ni mauvaise en soi...

Simplement, dans une situation donnée, il y a des solutions qui faciliteront le travail par rapport à d'autres - et/ou qui seront plus efficaces que d'autre - et qu'il sera clairement préférable d'utiliiser ;)

et bien je vous remercie de vos réponses :)

Je ne suis vraiment pas un fana des setters, mais alors pas du tout.

Quand j'ai vraiment des classes qui ne sont pas juste des banales aggrégations de données (auquel cas -> tout public), je cherche à avoir des getters pour les membres privés correspondant à des propriétés exposées, un constructeur d'initialisation et basta.

Sinon, je peux avoir des objets qui fournissent des services qui vont altérer l'état interne. Pour l'instant, rien qui s'apparente à de banaux setters.