Detection des enfants avant leurs construction

Version imprimable

10/02/2005, 22h20
qqchose

Detection des enfants avant leurs construction

Bonjours,

Pour expliquer ma question je vais prendre un exemple simple, mais concret.

Supposons une classe abstraite "Chien". De ce classe plusieurs enfants seront créer, par exemple, bulldog, Huski, bergerAlmand...
Ensuite, je crée une classe "listeChien". cette classe consiste a crée un vecteur qui contiendra un pointeur de (Chien) de chacun des enfants existants. Donc, dans son constructeur, je creer un instance de chacun des enfants et je met sont adresse dans le vecteur.

Ma question est la suivant, y a t'il une methode pour que la classe "ListeChien" detecte tout seul tout les enfamnts de "chien"?
Présentement, a chaque fois que je creer un nouveau "chien" je vais ensuite ajouter dans le constructeur de "listechien" des ligne de commande pour creer se nouveau chien et l'ajouter au vecteur. m'ais j'aimerais que si je creer un nouveau chien, la classe detectera automatiquement que ce chien existe.

Bref, j'aimerai connaitre une facon de detecter tout les enfants disponible d'une classe abstraite.
Merci
10/02/2005, 22h33
Laurent Gomila

Pourquoi pas ajouter simplement this à ta liste dans le constructeur de la classe mère, plutôt que dans celui de tous les enfants ?
10/02/2005, 22h35
Luc Hermitte
J'hésite entre : "tu cherches à faire une flyweight-factory" et "je n'ai rien compris à ton problème". Ou alors, tu veux juste enregister le nouveau chien à un singleton
Code:

1 2 3 Chien::Chien(params p) : ...... { liste_chiens::instance()->register(this); }
? (mais ce n'est pas très propre je trouve ; je préfère centraliser les créations dans une factory qui elle se chargera d'enregistrer les nouveaux chiens).
BTW, je ne trouve pas l'héritage d'interface très adapté à la modélisation d'animaux d'autant plus quand ils sont de la même espèce.

Eventuellement nous montrer un petit exemple orienté utilisation de ce que tu cherches à faire (les tests unitaires en quelque sorte)

J'avoue que l'exemple de chien laisse à désirer, mais j'avais cru que cela serais claire. faut croire que non.

Pour debuter, oui, chacun des enfants suit la pattern (du moins en partie)du singleton, ainsi que la "liste".

Pour l'idee de mêttre "this" dans ma liste dans le constructeur de la classe abstrait n'est pas une solution valide. Car, en fesant cela, chacun des enfats sera ajouter à ma liste a la creation de cette enfant. Qui n'est pas du tout mon intention. Chacun des enfants, suivant le singleton (1 seul instance possible), seront crée à l'interieur du constructeur de la liste. en autre mot, La seule facon de d'appeler le constructeur des enfants est de passer par le constructeur de la liste. Donc, aucune instance d'enfant existe avant l'appelle du constructeur de la "liste" et aucune instance d'enfants ne sera creer apres son appelle.

Je vais donner une exemple de mon vrai programme. Je fait une carte composer de tuile. Tuile est une classe abstraite. Ensuite les classe "sol", "mur" et "eau" sont des enfant de "tuile" et sont abstraite. Prenons "Sol" comme exemple. Une classe "Sable" est un enfant de "Sol".

Ensuite je veut afficher a l'utilisateur la liste des tuile disponible. Donc, j'ai fait une classe "TuileDispo". Dans le constructeur de "TuileDispo", je crée une instance de chacun des enfants existants.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 TuileDispo::TuileDispo(TWinControl* parentSol, TWinControl* parentMur, TWinControl* parentEau) { //m_liste est un vecteur de (Tuile*) Tuile* t = new Riviere(parentEau); //Riviere etant un enfant de Eau m_liste.push_back(t); t = new Sable(parentSol); //Sable etant un enfant de Sol m_liste.push_back(t); t = new Gazon(parentSol); //Gazon etant un enfant de Sol m_liste.push_back(t); t = new HerbeBasse(parentSol); m_liste.push_back(t); .... }
de cette facon, je peu connaitre tout les tuiles existantes. Mais le probleme viens du fait que je doit ajouter une ligne de code de genre
Code:

1 2 3 t = new NouvelleClasse(parent); m_liste.push_back(t);
a chaque fois que je creer une nouvelle classe. Personnellement cela ne me derange pas, mais comme je ne suis pas le seul a programmer, cela peut etre agacant. Sourtout que l'ordre a une importance majeurs lors de la sauvegarde et du chargement

Donc, y a til une autre facon de creer une instance de chacun de enfants sans etre oubliger de specifier formellement le type a creer.

NB: Je n'ai aucun bog a corriger, je ne voudrait que facon à optimiser.

11/02/2005, 02h54
Luc Hermitte

Hummm.
Je me trompe ou ce que tu appelles "enfant" n'a rien à voir avec la notion d'héritage du C++ ? Dans le cas où cela à bien à voir, alors pourquoi passer un paramètre immuable connu par construction (ou devrais-je dire "conception") à tes constructeurs ?

Ensuite pour le peu que je comprenne à ce que tu cherches à faire, tout cela me parait ressembler fortement à une flyweight factory. Loulou met à disposition un tutoriel qui présente diverses choses dont ce Design Pattern (au pire, il y a le GoF, le Portland Pattern Repository, dotfactory, un fil sur des ressources sur les DP dans le forum de méthodologie objet, ...)

Enfin, l'héritage ne me parait pas hyper indiqué. En quoi les spécialisations (des implémentations des interfaces publiques) de ces diverses classes justifient un héritage, et même de définir autant de classes que de terrains possibles ?

En isolant correctement les caractéristiques des divers terrains tu devrais arriver à une solution générique avec 0 héritage (mais de la composition pour chaque caractéristique (texture, coefficients de déplacement, malleabilité, absortion, résistance, ...)) et ainsi étendre à volonté tes tuiles juste via des fichiers de configuration qu'il suffira de charger.
11/02/2005, 03h33
qqchose
Ton idee ressemble a mon idée original. Cependant, j'étais arrivé avec quelque probleme. Dans le fond, tu m'explique de ne faire qu'une seule classe, mais de modifier ces attributs (proriétés). Le probleme arrive lorsque j'utilise les fonctions. Prenons une exemple. La fonction marcheSur(...) est une fonction qui est appelé lorsque quelquechose se place sur la tuile. Cetaine tuile declancherons un action differente. Cest pour cette raison que j'ai implanté
Code:

1 2 virtual void marcheSur(...) = 0;
dans la classe tuile.
Comme ca, chacune des tuile peut faire leur action spécifique. Ce que je ne pouvais pas faire en mettant qu'une seul classe et en editant les instance de cette classe pour lui attribuer des valeurs differente pour chaque tuile.

pour ce qui est du pattern "flyweight factory", jai lu vagement, cela semble convenir. Cependant j'ai eu de misere a bien la comprendre. Je vais continuer a l'étudier

Merci
11/02/2005, 03h42
qqchose

Je viens de comprende le pattern flyweight factory.

Le probleme, ce que , dans le fond, j'étais entrain de l'utilisé d'une certaine maniere . Ce que j'en conclue, il n'y a pas de meuilleur methode.

Merci
12/02/2005, 03h37
Luc Hermitte
Avec le pattern commande, tu peux faire le lien avec une action à exécuter qui sera externe aux cases.
A la place tu vas avoir un ensemble de classes de commandes que tu sauras lier à un élément dans les fichiers de script. Fichiers qui pourraient ressembler à
Code:

1 2 3 4 5 6 <sol ppt1="toto" marchesur="nil"> <dalle materiau="pierre" ...> <dallepression marchesur="piegepression"/>  </dalle> </sol>
On retrouve un héritage de propriétés. Avec une autre syntaxe (j'ai du mal avec xml...) on peut faire des choses plus poussées comme une sorte d'héritage multiple et alos définir de nouveaux éléments par composition de traits.

Dans le fichier de description de carte, on peut alors indiquer des zones de dalles et au milieu : des dalle-pression reliées à des pièges à gaz, et qui peuvent avoir un seuil de camouflage à 15, et un seuil de désormorçage à 30.

Il n'y a pas vraiment besoin d'héritage au niveau objet.. Sinon entre les dalles-pression, les trous recouverts de baches, ... on ne peut pas s'en sortir sans avoir une hiérarchie qui explose, et gêne à l'évolution du moteur.
12/02/2005, 06h18
qqchose

Ouhaaaa...

Tu me donne l'impression d'être vraiment null. 8O
Je ne suis pas sur d'avoir tout saisie, alors si tu me le permet, je vais essayer de résumer.

Dans le fonc, tu me dit des faire des classe "action" qui ces classe seront associé aux instances de tuile. comme ca, lorsque la méthode(fonction) marcheSur(...) est appeller, l'objet ira voir la liste des ces actions disponible et declacher la bonne. Comme par exemple, faire une action de piege. Quelque tuile pourra avoit cette action.

Je suis completement dans le champs, ou je ne suis pas si pire?

Cela me parait ça.
En schématisant (je ne mets pas la partie chargement de config depuis fichiers qui n'est pas forcément triviale -- je n'ai pas réfléchi aux détails), on aurait un truc du style:

Code:

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
struct commandeMarcherSur 
{
    virtual 
    type_resultat // est-ce vraiment utile ? je ne sais pas
    do(
        /*in,out*/ type_entite & marcheur, 
        /*in,out*/ type_case   & case)
    {} // implémentation vide par défaut
};
 
struct commandeMarcherSurPiege : commandeMarcherSur 
{
    virtual 
    type_resultat // est-ce vraiment utile ? je ne sais pas
    do(
        /*in,out*/ type_entite & marcheur, 
        /*in,out*/ type_case   & case)
    {
        if (marcheur.test_reflexes(piege_.getSeuilEsquive())) {
            piege_.declenche(marcheur, case);
        }
    }
 
    commandeMarcherSurPiege(
        type_piege_descripteur & piege_descripteur) 
    : piege_(piege_descripteur)
    {}
private:
    type_piege piege_; // une instance de piege se construit à 
                       // partir d'une description de piege
};
 
struct type_case
{
    ....
    void traversePar(type_entite & marcheur) {
        if (entite.enTrainDemarcher())
            actionMarche_->commandeMarcherSurPiege(marcheur,*this);
        else ...
        // on doit pouvoir faire beaucoup mieux avec le patern state
    }
private:
    commandeMarcherSur  * actionMarche_;
    // se construirait aussi depuis une description de commandeMarcherSur
};
 
struct type_piege 
{
    type_seuil   getSeuilEsquive() const;
    type_quantite quantiteDegats() const;
 
    void declenche(type_entite & entite, type_case & case) {
         entite.recoitDegats(categorie_degats_, quantiteDegats());
         if (--nb_charges_) 
             case.changeActionMarche("nil");
             // avec de l'héritage, on aurait été embétés à devoir 
             // changer le type de l'objet courant. Là, c'est juste un 
             // attribut qui change
             // Et attention au "delete this;" => à refactorer peut-être
    }
 
private:
    // ensemble(=champs de bits)
    type_categorie_degats categorie_degats_; 
 
    int nb_charges_; // init à 1 pour la majorité des pieges.
};

Le design est loin d'être parfait, mais il traduit assez bien ma vision des choses.
Il faudrait probablement s'y prendre autrement pour les pièges. En effet certains infligent des dégats de type "fais dodo", d'autres sont rechargeables (ce qui implique de laisser la possibilité de réarmer l'action ; peut-être avec un autre type de commande qui fonctionne comme une bascule (genre le levier, ...) ?), ...

PS: pas une question de nullité. D'expérience peut-être ?

12/02/2005, 17h39
qqchose

Merci

Je vais retourner faire mon analyse pour faire un these des avantange inconvénient pour mon cas spécifique. Apres tout, mon projet étant loin d'etre fini et que mon diagramme UML fait plus de 2 pages, il y a certaine chose que tu ne sais pas. Mais ta metode a attirer énormement mon attention. Apres ma these, j'irai en discuter avec mon partenaire.

Merci pour tout