Discussion :

[Lavock]

Bonjour à tous,
J'ai actuellement un souci de conception. Je n'en suis pas sur, mais mon design à l'air foireux, et je n'arrive pas a savoir pourquoi (du coup, encore moins comment le résoudre).

Globalement, une class client demande à un objet:
1 - Des renseignement quant à sa position géographique;
2 - Des renseignement concernant sa composition materiel.

Soit, le client est roi. Temporairement, j'avais :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 class objet {
private:
  materiel * mat;
  data autreData;
public:
  quelconque renseignementGéographique1();
  quelconque renseignementGéographique2();
  const materiel & reseignementMateriel();
private:
  virtual quelconque vRenseignementGeo1() =0;
  virtual quelconque vRenseignementGeo2() =0;
}

Conscient du problème que cela posait (double resposabilité). Maintenant, je voudrais résoudre se problème... Mais voilà qu'une contrainte s'ajoute : un objet n'est plus définie comme avec un materiel unique. Selon les données retourné par renseignementGeo, je doit avoir différent retour de renseignement materiel. De plus, cela dépend aussi de la vrai (comprendre au sens polymorphique) nature de l'objet.

Le truc le plus "convaincant" qui est réussi à jaillir de mon esprit, c'est un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 class objet {
private:
  data autreData;
protected
  texture * tex;
public:
  quelconque renseignementGéographique1();
  quelconque renseignementGéographique2();
  const materiel & reseignementMateriel();
private:
  virtual quelconque vRenseignementGeo1() =0;
  virtual quelconque vRenseignementGeo2() =0;
  const materiel & vRenseignementMat() = 0;
}

Mais je dois dire que ça ne me convainc pas. Et, même si c'est tout bête (d'ailleurs ça l'est surement), je n'arrive pas à savoir pourquoi ça me dérange .

Si quelqu'un à une idée, merci pour l'aide >< !

[white_tentacle]

Je ne suis pas sûr d'avoir très bien compris (en fait, je suis sûr que je n'ai pas tout compris), mais j'ai envie de te conseiller de regarder du côté du pattern décorateur... Ça me semble adapté à ce que je comprends de ton cas.

[Lavock]

Oula, je vais jeter un oeil pour voir si ça me convient... Mais j'en suis pas sur (réponse Lundi). Le truc, c'est que je sais pas si je brise vraiment le SRP dans mon second cas...

En gros, j'ai l'impression d'avoir deux responsabilité (demande 1 et 2 du client). Mais je vois pas comment les "séparer" dans mon implémentation.

En tout cas, merci !

[koala01]

Salut,

Pourquoi ne pas prendre pour base une sorte de médiateur

D'un coté, tu aurais une classe "localisable", dont la responsabilité serait... de connaitre sa position, de l'autre une classe "matériel" correspondant au... matériel utilisable, et, entre les deux, une classe "médiateur" qui tiendrait à jour la liste des différents objets localisable et le lien vers les différents matériel qu'ils contiennent.

Ce serait vers cette classe médiateur que tu te tournerait pour "ajouter" un matériel à un localisable ou pour récupérer la liste des matériels dont il dispose.

Tu aurais ainsi quelque chose prenant la forme de

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
22
23
24
25
26
27
class Localisable
{
    /* uniquement ce qui a trait à la localisation */
};
class Materiel
{
    /* uniquement ce qui a trait au matériel */
};
class Mediateur
{
        /* par facilité, à usage interne */
        typedef std::map<Localisable*, std::vector<Materiel*> > map;
    public:
        typedef std::vector<Materiel*>::const_iterator const_iterator;
        /* si tu dois pouvoir disposer d'une correlation entre les deux
         * uniquement
         */
        typedef typename map::const_iterator rel_iterator;
        void registerLocalisable(Localisable *);
        void unregisterLocalisable(Localisable *); 
        void addMateriel(Localisable *, Materiel *);
        rel_iterator find(Localisable *) const;
        const_iterator materielBegin(Materiel *) const;
        const_iterator materielEnd(Materiel *) const;
    private:
        map items;
};

Les objets de type Materiel et Localisable étant bien entendu gérés par ailleurs

[Lavock]

Parce que c'est le genre d'opération que je fais plus de 10k fois lors d'une exécution... Si lorsque je cherche un matériel précis, je suis obligé en plus obligé de chercher dans une map un conteneur de matériaux, je vais pas m'en sortir...

En plus, il faudrait que j'ai une relation d'ordre quelconque sur objet (localisable), ce qui n'est pas fait, ne serait pas forcément logique, et couterait assez cher... Et si j'en fais pas, attention la catastrophe ><.

En fait, je sais que c'est une solution viable, mais elle me couterait vraiment trop cher...

[koala01]

En fait, il faut savoir combien d'objets différents tu va utiliser lors de tes 10 000 opérations, et, surtout, si tu effectue toutes les opérations relatives à un objet particulier "en une fois" ou si tu "switche" sans arrêt d'un objet à l'autre.

Si, effectivement, tu "switche" sans arrêt d'un objet à l'autre lors de tes opérations, la solution n'est pas viable, mais, si par contre, tu travailles longtemps avec un objet donné (quitte à passer l'ensemble des matériels qu'il utilise), la solution ne me parait pas si mauvaise que cela:

• Un pointeur n'est en réalité qu'une valeur numérique entière, et est donc un candidat idéal pour représenter une clé
• Tu dispose "naturellement" du pointeur sur l'objet en cours avec this
• La std::map effectue une recherche en log(n), c'est à dire que, toutes proportions gardées, tu récupérera l'objet recherché d'autant plus vite (par rapport au nombre d'éléments existants) que le nombre d'objets existants sera élevé
• tu garde deux relations 1 - N au lieu de devoir gérer des relations N - N
• les trois classes ne doivent, pour ainsi dire, rien connaitre l'une de l'autre: Localisable et Materiel ne doivent connaitre que la définition de Mediateur, et médiateur peut se contenter de... connaitre la déclaration des deux autres (étant donné qu'elle n'utilise que des pointeurs)
• Si tu effectue un maximum d'opérations sur un objet identique à chaque fois, tu peux même envisager d'accéder directement à l'ensemble des matériels qu'il utilise sans devoir repasser par la recherche de l'objet (bien que cela contredise "un peu" l'argument précédent selon lequel Localisable ne doit connaitre que Mediateur) avec, au final, un amortissement du temps passé à effectuer la recherche d'autant plus important que le nombre d'opérations effectuées augmentera
• tu sépare très clairement les différentes responsabilités de tes différentes classes

Autrement dit, cette classe devrait "uniquement" être épaulée par une classe s'occupant de gérer la durée de vie des objets et une autre gérant la durée de vie des matériels, et tout pourrait passer "directement" par elle en ce qui concerne la relation entre un objet donné et les matériels qui lui sont rattachés.

Maintenant, je me suis basé sur le fait que, au départ d'un objet particulier, nous tentions de récupérer les matériels qui y sont rattachés, mais, rien ne nous empêche d'envisager la relation inverse non plus, selon le type de recherche ou d'utilisation propre à ton problème