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

[Lavock]

A méditer, mais :

Si, effectivement, tu "switche" sans arrêt d'un objet à l'autre lors de tes opérations, la solution n'est pas viable,

Je suis plutôt dans se cas. Je vais voir si je peux changer ça....

En fait, il faut savoir combien d'objets différents tu va utiliser lors de tes 10 000 opérations,

Toutefois dans la plupart des cas, je manipulerai au plus une vingtaine d'objet (enfin, je crois). En tout cas, merci.

Bon, comme je suis pas sûr de grand chose sur l'utilisation final, je vais quand même réfléchir à d'autres solutions.

Sinon, est-ce que mon deuxième design était réellement mauvais ? et si oui, en quoi ?

[koala01]

Ton deuxième design n'est pas *réellement* mauvais, mais il est beaucoup moins souple...

Avec la solution que je propose, tu ne force quasiment aucune dépendance, mais tu garde la possibilité de tout regrouper vers "un point commun", alors que, si tu agrège tes matiériels dans tes objets localisables, tu renforce une dépendance qui n'est peut être pas *forcément* utile partout et qui *risque* d'avoir des effets pervers...

Si, plus tard, tu te retrouve avec des objets localisables ou des matériels trop particulier, tu *risque* d'assister à une explosion de classes.

Ici, en adaptant, pourquoi pas, le DP decorateur sur ta classe objet localisable, tu limites, à mon sens, grandement le risque.

Mais, quoi qu'il en soit, j'ai l'impression qu'il y a des questions auxquelles il serait "pas si mal" d'avoir une réponse avant de prendre la décision

[koala01]

En outre, à bien y repenser, si, lors de tes manipulation, tu dois travailler sur une sélection donnée d'objets localisables, rien ne t'empêche de faire toutes les recherche "d'une seule fois" et de récupérer les paires dans la collection la plus adaptée...

Une fois les paires placées dans la collection (std::vector, std::list, stack ou que sais-je), tu n'a "plus qu'à"... parcourir cette collection selon tes besoins )

[Lavock]

Mais, quoi qu'il en soit, j'ai l'impression qu'il y a des questions auxquelles il serait "pas si mal" d'avoir une réponse avant de prendre la décision

N'est-ce pas ? >< !

En outre, à bien y repenser, si, lors de tes manipulation, tu dois travailler sur une sélection donnée d'objets localisables, rien ne t'empêche de faire toutes les recherche "d'une seule fois" et de récupérer les paires dans la collection la plus adaptée...

Cette idée me plaît bien. Surtout que je peux, dans un premier temps, me contenter d'implémenter ta première solution, pour ensuite améliorer la gestion mémoire si jamais cela devient un point critique ( encore une fois).

Ici, en adaptant, pourquoi pas, le DP decorateur sur ta classe objet localisable, tu limites, à mon sens, grandement le risque.

Je garde aussi la piste de white_tentacle, du moins pour éviter "l'explosion de classe", même si je voit pas trop comment l'adapter à mon problème pour l'instant.

En tout cas, merci à vous !

[koala01]

N'est-ce pas ? >< !

Oui, mais celle là était justement facultative

Cette idée me plaît bien. Surtout que je peux, dans un premier temps, me contenter d'implémenter ta première solution, pour ensuite améliorer la gestion mémoire si jamais cela devient un point critique ( encore une fois).

Exactement

Je garde aussi la piste de white_tentacle, du moins pour éviter "l'explosion de classe", même si je voit pas trop comment l'adapter à mon problème pour l'instant.

C'est surtout pour le cas où tu te rendrait compte à l'usage que tu te trouve dans une situation dans laquelle tu devrait muliplier les classes héritant de localisable avec des interfaces particulière parce que n'utilisant que des matériels particulier...

[Lavock]

Je me disais bien que j'avais oublié un truc >< :

De plus, cela dépend aussi de la vrai (comprendre au sens polymorphique) nature de l'objet.

Si je rend la classe texture visible depuis l'extérieur, je vais devoir "obliger" l'utilisateur à faire un truc genre :

Code :

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

1
2
3
4
5
 
typedef std::pair<localisable,texture> objet;
 
...
object.second.getMaterial(objet.first.getIndice());

Remarque, je peux toujours encapsulé dans un demeter-like objet :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class objet {
    std::pair<localisable_et_texturable,texture> value;
public:
    getMaterial(){
        value.second.getMaterial(value.first.getIndice());
     }
    getGeo() {
        value.first.getGeo();
    }
    //etc...
};

Mais est-ce que c'est toujours aussi bien ?

[koala01]

Je présumes (mais je peux me tromper) que ton getIndice correspond à la phase d'affichage à utiliser...

Mais, si c'est le cas, crois tu *réellement* que la responsabilité de gérer cet indice échoie à ton objet localisable

Si, de fait, la gestion de cet indice n'échoit pas à tes objets localisables, j'aurais tendance à dire que ma solution reste tout à fait valide...

D'autant plus que, si l'on excepte le problème d'accessibilité qui peut se poser du fait du typedef privé, nous avons réellement une relation tout à fait artificielle, dont tu peux décider de tenir compte (en manipulant la paire)... ou non (en récupérant le pointeur sur objet d'un coté et le tableau sur textures de l'autre)...

[EDIT]De plus, l'apposition d'une texture quelle qu'elle soit ne devrait pas être de la responsabilité de ton objet, qui ne devrait, en gros, que donner les triangles sur laquelle l'appliquer, mais... de ton système d'affichage.

Enfin, j'ai réellement le sentiment que, la plupart du temps (hors affichage), il n'est pas nécessaire que l'objet se trimbale en permanence les textures dont il est composé: ce n'est jamais qu'un effet visuel

[Lavock]

Je présumes (mais je peux me tromper) que ton getIndice correspond à la phase d'affichage à utiliser...

Non, il s'agit d'un pré-calcule qui détermine les propriétés locales de l'objet (ou plutôt ou est-ce que se trouve cette propriété local par rapport à une origine).

Mais, si c'est le cas, crois tu *réellement* que la responsabilité de gérer cet indice échoie à ton objet localisable

Non, justement, j'ai l'impression que c'est "à part". Malheureuseument, mathématiquement cela dépends bien de l'implémentation de localisable ><. C'est là tout mon problème...

D'autant plus que, si l'on excepte le problème d'accessibilité qui peut se poser du fait du typedef privé,

ou ça oO ?

nous avons réellement une relation tout à fait artificielle, dont tu peux décider de tenir compte (en manipulant la paire)... ou non (en récupérant le pointeur sur objet d'un coté et le tableau sur textures de l'autre)...

Pas possible, cf. ce que je viens de dire :'(.

[EDIT]De plus, l'apposition d'une texture quelle qu'elle soit ne devrait pas être de la responsabilité de ton objet, qui ne devrait, en gros, que donner les triangles sur laquelle l'appliquer, mais... de ton système d'affichage.

Enfin, j'ai réellement le sentiment que, la plupart du temps (hors affichage), il n'est pas nécessaire que l'objet se trimbale en permanence les textures dont il est composé: ce n'est jamais qu'un effet visuel

Je ne peut pas travailler dans l'approximation des "triangles" et de la raster. Je suis plus précis que ça .

[EDIT] Après y avoir réfléchis, la meilleurs solution semble celle de white_tetacle mélangé à la tienne => adoption de "pair" et du classe qui gère leur relation + pattern décorateur. Ce que tu me propose semble la seul solution suffisemment souple pour pouvoir adopter un pattern decorateur, histoire que mes textures soient belle est bien des "décoration" de mes localisable.

PS : Je mettrai le topic en résolu demain si j'ai pas changé d'avis >< !

[Lavock]

Et zut, je vois pas non-plus comment faire un pattern décorateur si la décoration dépend de l'implémentation du produit ><...
Surtout que, a y avoir réfléchis, certain localisable ne peuvent effectivement pas avoir certaine texture... En gros, j'ai des pré-conditions à l'application de certaine texture.

Mais est-ce que mon vrai problème est de rendre indépendant le calcul d'une propriété locale d'un localisable de son implémentation ? Et si c'est impossible.

Comment faire en sorte que seul l'ajout d'une implémentation de localisable me fasse modifié un localisable... Et que je n'ai pas à retoucher ces classes si j'ajoute une texture particulière ?

J'ai vraiment l'impression d'avoir manquer quelques chose, mais du coup, ma seul solution valide devient celle de la rigidité, et ça me plaît pas ! Je me restreint d'avance certaine possibilité ><.

[koala01]

En fait, je me demande si tu ne fais pas carrément fausse route depuis le début...

Si j'ai bien compris, ta notion de localisable est, typiquement, une notion qui va se balader partout et s'appliquer à plein de choses différentes...

Si tu étais occupé à travailler sur un jeu, je n'hésiterais pas à dire que cette notion s'applique aussi bien à un pan de mur (ou n'importe quel élément de décors) qu'à des armes ou à des éléments vivants (joueurs, PNJ's, monstres et bestioles en tous genres) et que tu en as besoin aussi bien au niveau de la gestion plateau de jeu qu'au niveau de l'affichage, du moteur de jeu ou de l'IA.

Cette notion devrait en fait uniquement permettre de dire où la "chose" se trouve et, le cas échéant, la direction dans laquelle elle est orientée, voire, permettre de savoir si la "chose" est en mouvement (comprend: se déplace sur la surface de jeu).

La texture, de son coté, n'a réellement un intérêt que... au niveau de l'affichage, parce que, partout ailleurs, on n'en a rien à foutre que tel objet soit vert, rouge, gris ou jaune à petit pois

Il n'y a donc aucun intérêt à faire en sorte que les objets qui sont localisables se baladent dans tout le projet en "trainant derrière eux" ce genre d'informations.

De plus, j'aurais tendance à ajouter auprès de ces deux notions complémentaire une troisième qui serait celle du "volume occupé" (la forme prise par les différents objets et leur représentation "dans l'espace"), qui serait utilisée principalement dans le système d'affichage et le moteur de jeu

La "posture" (bras gauche levé, jambe droite en arrière; couché; assis; un doigt dans le pif,...) de cette troisième notion serait calculée par le moteur de jeu et le système d'affichage s'occuperait d'appliquer les différentes textures sur ce volume avant... de l'envoyer à l'écran...

Mais il s'agit de trois notions finalement tout à fait orthogonales, qui se "rejoignent" à certains points clé du projet pour permettre la fourniture d'un service donné

[Lavock]

Oui, tu décris la le principe d'une bonne vieille raster... Seulement, je ne fais pas un jeux. Ainsi, dans une pièce carré banale avec une lampe, une chaise et un sole blanc :

L'ombre de la chaise sur le sol ne sera pas de la même "couleur" selon que les murs soit blanc ou noir, ou même selon leur angles par rapport à la lumière !

En gros, la technique que j'utilise est plus proche du ray-tracing... Donc dans cet état d'esprit, je suis obligé de "traîné" les textures avec les "localisables".

[koala01]

Oui, tu décris la le principe d'une bonne vieille raster... Seulement, je ne fais pas un jeux. Ainsi, dans un jeu, dans une pièce carré banal avec une lampe, une chaise et un sole blanc :

L'ombre de la chaise sur le sol ne sera pas de la même "couleur" selon que les murs soit blanc ou noire, ou même selon leur angles par rapport à la lumière !

En gros, la technique que j'utilise est plus proche du ray-tracing... Donc dans cet état d'esprit, je suis obligé de "traîné" les textures avec les "localisables".

Non, pas forcément...

Tu dois, effectivement, les faire se rejoindre, mais uniquement au niveau de l'affichage, ou, plus précisément, du calcul de rendu...

Partout ailleurs (comprend: en dehors du système de calcul de rendu), il n'y a aucune raison pour trainer ces trois informations: le moteur de jeu ou l'IA, et même, dans une certaine mesure, le système de définition du plateau (bien qu'il ai besoin des information "volumétriques") se foutent royalement des textures

Bon, ici, je continue dans l'optique "jeu", à défaut de savoir ton champs d'application, mais c'est adaptable pour le reste

[Lavock]

Tu dois, effectivement, les faire se rejoindre, mais uniquement au niveau de l'affichage, ou, plus précisément, du calcul de rendu...

Je ne fais que ça >< !

[koala01]

Je ne fais que ça >< !

Je dirais presque que c'est une raison supplémentaire pour garder quelque chose d'aussi souple que possible...:

Etant donné que tu sais que ton travail est destiné à être intégré dans un projet au sujet duquel tu n'a pour ainsi dire aucun contrôle sur les évolution futures, tu dois veiller à faire quelque chose qui pourra évoluer dans tous les sens, sans crainte de devoir, à un moment donné, ni "tout casser" ni provoquer des régressions importantes.

Plus tu gardera tes relations faibles pour ne pas dire artificielles, plus les évolutions futures seront simplifiées