Discussion :

[tintin72]

Bonjour,

J'ai un gros pb avec la représentation informatique d'un objet.
L'objet en question est une sorte de petit panneau de configuration.
Les attributs le représentant sont le plus souvent des flags (est ce que tel
bouton est coché etc....) ainsi que d'autres objets (composition) utilisés pour son fonctionnement
interne mais ces objets ont leurs propres mode de gestion.
Maintenant si je matérialise tout ça, je me retrouve avec une classe qui ne possède
quasiment que des accesseurs/mutateurs ce qui est le signe d'une mauvaise conception.
Donc pour l'instant la seule solution que j'ai trouvé c'est d'en faire une struct (un type)
contenant toutes les variables/attributs nécessaires.
Cette struct est ensuite utilisé par la classe qui s'occupe de la création/gestion de cet objet (il peut y en
avoir beaucoup) sous la forme d'un vector de pointeur sur cette struct.
La classe propose ensuite un accesseur qui retourne un pointeur avec lequel l'utilisateur
peut accéder au variables de la struct.
Bon je sais ça fait pas très P(r)OO tout ça, surtout au niveau de l'encapsulation
des données, mais j'ai beau retourner le pb dans tous les sens je vois rien d'autre.

Donc voilà, j'aimerais savoir s'il existe une autre façon de faire/voir les choses ou si
dans certaines situations on ne peut tout simplement pas faire autrement ?

Merci de m'éclairer.

[Médinoc]

Tu sais, même en POO il n'est pas interdit d'avoir des POD.
Je ne vois pas de problème à séparer le Modèle et la Vue, ou séparer le Modèle et le Contrôleur...

[gahanima]

En quoi le fait de n'avoir que des accesseur/ mutateur est il le signe d'une mauvaise conception ?

De même que Médinoc je ne vois pas où est le problème.

[Médinoc]

Je te conseille d'utiliser des variables membres publiques, sauf si certaines variables ont un domaine restreint (genre, 0 < uneVariable < 1000). Car là, utiliser un accesseur est intéressant.

[tintin72]

En quoi le fait de n'avoir que des accesseur/ mutateur est il le signe d'une mauvaise conception ?

En général quand on créé une classe c'est pour lui faire faire quelque chose, même si
c'est très simple (multiplier un nombre par 2, retourner sa racine carré etc...).
Une classe qui n'a que des accesseurs/mutateurs ne fait rien sinon regrouper quelques
variables et fournir des méthodes pour y accéder.
Autant tout mettre dans une struct et en faire un nouveau type, c'est plus simple.

Sinon selon Herb Sutter et Andrei Alexandrescu:

Les fonctions d'accés get/set sont utiles, mais une classe composée en majorité de ce type de fonctions est certainement mal conçue: choisissez de fournir une vraie abstraction ou de transformer votre classe en struct.

[Médinoc]

Mais comme je dis, ça peut être l'équivalent d''une struct qui vérifie l'intégrité de ses données". Les accesseurs et mutateurs ne sont pas forcément ultra-triviaux...

[HanLee]

En général quand on créé une classe c'est pour lui faire faire quelque chose, même si
c'est très simple (multiplier un nombre par 2, retourner sa racine carré etc...).
Une classe qui n'a que des accesseurs/mutateurs ne fait rien sinon regrouper quelques
variables et fournir des méthodes pour y accéder.
Autant tout mettre dans une struct et en faire un nouveau type, c'est plus simple.

Sinon selon Herb Sutter et Andrei Alexandrescu:

Pour simplifier, qu'attends-tu de ton objet ?

Qu'il te fournisse un réel service, un structure un peu sophistiquée avec des invariants à maintenir ? class
Ou bien qu'il soit juste une aggrégation brute de données, au même titre qu'un int, float, std::pair<> ? struct (ou class avec tout public)

[tintin72]

Mais comme je dis, ça peut être l'équivalent d''une struct qui vérifie l'intégrité de ses données". Les accesseurs et mutateurs ne sont pas forcément ultra-triviaux...

Oui oui, je comprend tout à fait ton point de vue, mais dans mon cas je n'ai
pas vraiment besoin de vérifier l'intégrité des données.

Pour simplifier, qu'attends-tu de ton objet ?

En fait en y réfléchissant bien il s'agit d'une espèce d'objet "public"
qui est consulté/modifié par certaines parties/classes du programme.
Ces classes se renseignent sur "l'état" de l'objet et agissent en conséquence,
elles peuvent également le modifier.
Finalement cet objet ne peut pas faire grand chose sinon exposer l'état de
ses attributs.
Au début j'ai tiqué justement sur cette "exposition sauvage" (pas d'encapsulation ni rien)
mais je crois que dans ce cas précis c'est la bonne coordination entre les classes
qui utilisent cet objet qui garantie la stabilité du code.
Je suppose donc qu'une aggrégation brut serait la meilleure option.
En tous cas c'est la 1ere fois où je me confronte à ce genre de conception où on
sait pas trop si c'est du lard ou du cochon.

[Médinoc]

Si tu n'as pas besoin de vérifier l'intégrité des données, alors une struct ira très bien.

[koala01]

Salut,

Une question que tu devrais surtout te poser, car, comme l'a dit Médinoc, une structure est quelque part déjà suffisante, est

La représentation réelle des champs de la structure risque-t-elle réellement dévoluer

Je veux dire par là, te poser la question de savoir si un tableau C style (non dynamique) court réellement le risque d'être remplacé par un conteneur de la STL (ou de boost), par exemple, dans "la version suivante" (si tu en prévois une).

Si, effectivement, tu considère qu'il est réellement possible que cela arrive, la deuxième question à se poser est alors de savoir où se font les accès aux champs de la structure en question.

S'il n'y a qu'une ou deux classes (ou fonctions) à toi (par opposition à une classe ou une fonction écrite par quelqu'un qui utiliserait une bibliothèque que tu crées... si c'est le cas) la structure reste sans problème un bon choix: une modification éventuelle de la représentation des champs de la structure n'aura qu'un impact "limité" sur le code qui deviendra obsolète.

Si, par contre, la structure est utilisée "à toutes les sauces", qu'il y a des accès (en lecture comme en modification) "disséminés dans tout ton code", ou pire, que l'utilisateur de la bibliothèque (si tu en fais une, bien sûr) est susceptible d'accéder "à sa guise" aux différents membres, le seul fait de permettre une "compatibilité entre les versions" devrait t'inciter à ne donner qu'un nombre restreint de "points d'accès" aux informations, et donc à augmenter le niveau d'encapsulation, en passant à une classe munie des mutateurs et accesseurs qui lui sont utiles

Ce sera en effet la seule solution pour être réellement sur que, si un jour, la représentation réelle des champs de la structure évolue, tu ne sera pas obligé de rechercher chaque accès aux champs de celle-ci parmi des milliers de lignes de code réparties dans un nombre important de fichier (sans compter celle auxquelles tu n'aurait pas accès parce qu'écrites par un utilisateur "lambda" de ta bibliothèque)