Discussion :

[koala01]

Salut,

Soit une classe ayant comme membre quatre ou cinq vector ou map différents.

Evidemment, une grosse majorité des fonctions membres des vector et des maps est intéressante au niveau de la classe elle-même.

En plus, pour corser le tout, il n'est pas impossible que deux membres distincts soient des map contenant le meme type de données...

Pour respecter l'esprit de l'encapsulation des données, il faudrait déclarer ces membres privés et coder pour chaque membre les fonctions qui vont bien, c'est à dire surement cinq ou six fonctions par membres afin de pouvoir les manipuler...

Le résultat serait une classe comprenant une grosse trentaine de fonctions membres (si pas plus) qui... se contenteront de reproduire le comportement des vector et des map, selon les membres de la classe

Dans une telle situation, quels sont ceux d'entre vous qui décideraient de se faciliter la vie (quitte à rendre le maintien du code plus difficile) en déclarant les membres public et ceux qui préféreraient respecter en tous points le principe d'encapsulation en les déclarant privé, quitte à ce que cette classe ne soit pas sensée évoluer par la suite, sachant que le patern "facade" sera vraissemblablement utilié pour la gestion réelle de cette classe

Autant prévenir tout de suite, je n'ai absolument pas besoin des interventions qui auraient pour but de me convaincre de l'intérêt d'encapsuler les données...

Merci, je connais les avantages de l'encapsulation, et j'en suis bien conscient

Simplement, je n'ai pas de position précise sur la question, ma logique tendant à me faire choisir l'encapsulation, ma fainéantise naturelle tendant à me faire choisir les membres publiques...

Si je pose la question, c'est que, à tord ou à raison, j'envisage de m'allier à l'avis le plus souvent exprimé

[Mat007]

Salut,

Soit une classe ayant comme membre quatre ou cinq vector ou map différents.

Fichtre ! Y'a vraiment pas moyen de découper un peu plus ?

Pour répondre à la question : j'encapsule à tout prix.
Néanmoins je ne me souviens pas m'être retrouvé dans ce genre de situation.
D'expérience j'aurais tendance à dire que les interfaces de type conteneurs (sur lesquels on fait des 'get') sont incompatibles avec les interfaces de type orienté objet (qui sont supposé recevoir des demandes de traitements).
Du coup les endroits où des conteneurs sont utilisés sont normalement facilement encapsulables.

Y'a un moment où il faut mettre un frein à l'entropie des accesseurs sinon ça devient vraiment beaucoup plus difficile d'encapsuler des données derrière des demandes de traitement...

Tu parles de 'pattern' facade mais j'ai plus l'impression qu'il s'agit là d'une classe de type 'manager' qui ne propose aucun traitement ?
Ces données ont vraiment besoin de se trouver toutes dans la même classe ?

Je ne suis pas sûr que ça réponde à la question finalement

MAT.

[koala01]

Pour mon malheur, la classe dont je présente les caractéristiques est réellement à considérer comme une classe à part entière, et tous les membres doivent se trouver dans cette classe, meme si, de fait, elle prend réellement l'apparence d'un manager...

[mchk0123]

Si j'était toi, j'essayerais de trouver une solution qui satisfasse tes 2 demandes : conserver l'encapsulation, et être fainéant.

Les puristes du C++ trouverons que c'est une hérésie, mais dans la pratique tu peux t'en sortir en utilisant une macro :

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
#define DECLARE_MAP_VAR(varname) std::map<T,U> varname;
#define DECLARE_MAP_ACCESSORS(varname) \
  U get_##varname(const T &key); \
  void set_##varname(const T &key, u &value); \
...
class ma_classe {
  public:
    DECLARE_MAP_ACESSORS(var1);
    DECLARE_MAP_ACESSORS(var2);
    ...
  protected:
    DECLARE_MAP_VAR(var1);
    DECLARE_MAP_VAR(var2);
    ...
};
...
ma_classe<string, string> c;
 
c.set_var1("clef1", "val1");
c.set_var2("clef1", "val1");
...

Je penses qu'il doit aussi exister une solution à base de template, mais personnellement je n'en ai jamais mis en oeuvre dans cette situation. Donc je ne peux pas t'aider là dessus.

Enfin dernier détail. Normalement lors que l'on utilise le pattern facade, les méthodes publiques de la facades sont sensées contenir du code métier et pas simplement une délégation directe (aka accésseurs). Si c'est le cas c'est qu'il y a surement une erreur dans la conception de ton architecture OO.

[Luc Hermitte]

Je ne suis pas un fervent partisant des accesseurs à tout prix. Voyez la FAQ pour cela -- Aurélien y avait repris une partie de ma prose.

Une question très importante a été soulevée. C'est une classe n'aggrégeant que des données, ou bien une classe qui contient du code métier ?

Dans le premier cas, autant filer l'accès direct. L'interface publique de la classe ... ce sont les données qu'elle nous expose.

Dans le second cas, accesseurs ! Dernièrement, j'ai écrit 2-3 petites classes qui devaient stocker une table associative lue depuis un fichier, et permettre d'accéder au label associé à une paire d'identifiants. Les besoins sont parfaitement identifiés : ajout et récupération. Pas de parcours, pas de recherche de présence, pas de comptage, ...
Ce que j'ai fait, cela a été de définir une petite classe contenant deux fonctions : add() et operator[]()const. Chacune des deux ayant la responsabilité de lever une exception en cas d'ajout pour la même clé, ou en cas de récupération pour une clé non renseignée.
Le code étant très métier, j'ai tout encapsulé.

Maintenant, si ta classe est hybride, comme pour les autres intervenants, cela me donne l'impression qu'il y a des trucs à revoir dans le design.


Je pense à un truc. Ton problème ressemble aussi à celui d'une facade qui dot transmettre tous les messages reçus aux composant aggrégés. C'est ça d'une manière générale, ou bien tu n'aggrèges vraiment que des containers ?

[koala01]

En fait, j'aurais presque tendance à dire que cette structure pourrait tres bien ne se comporter que comme une struct C...

Elle se contenterait d'agréger des données, et de permettre éventuellement à un élément se trouvant dans le troisième membre de savoir si le premier membre contient tel ou tel élément...

D'un autre coté, tout le code réellement métier (gestion des éléments des différents membres) serait, lui, dévolu à des classes particulières (pour le chargement/la sauvegarde dans des fichiers, pour l'interfacage avec une GUI...)

J'avouerai que, pour ma part, j'envisage d'utiliser, carrément une structure plutot qu'une classe, histoire de me laisser aller à ma fainéantise naturelle...

Finalement, la question aurait tres bien pu être: "pousseriez vous de grands cris si, les choses étant posées, vous deviez rencontrer une classe dont tous les membres seraient publics, sachant que normalement, il n'y a aucun acces direct à cette classe"

Visiblement, cela ne semble déranger personne, ce qui me conforte dans l'idée de me laisser aller à la facilité

[mchk0123]

1. Avoir à se creuser la tête pour implémenter une Facade sont souvent liés à un mauvais design !
2. Mettre tous les attributs et les méthodes d'une Facade en visibilité publique c'est comme ... !
3. Tu ne peux pas nous dire 2 mots sur la nature de ton programme, quels données sont modélisées pas tes map, et qu'est-ce que ta facade est sensée faire ?
4. Ma solution à base de macros ne te convient pas ?