[conception] pb de Définition de classe par bouclage générique

Bonjour,

Je n'en suis pas à l'étape de codage mais plutôt de la conception papier et après avoir tourné mon pb sous différents angles, je n'ai que des solutions "impropres". Je considère ces solutions comme des contournements du C++ et donc vous demande assistance.

Pour avoir une substance à discuter, je vous donne tout d'abord l'objectif recherché :

Soit 1 classe objet générique représentative de ce que je pourrais appeller FORME.
Soit une méthode astucieuse pour coder une forme quelconque (ex : un carré, un cercle, deux tores, de la mousse, etc.). Cette construction utilise l'agrégation itérative : objetA := liste d'objetB:= liste d'objetC... jusqu'à un niveau terminal que je nommerais Z pour la forme. L'objet A pouvant être considérer comme représentation générale de la dite FORME.

Cependant tous ces objets sont des FORMEs en eux même (sauf la forme terminale si on veut), tout du moins c'est ce que je souhaiterais afin de m'abstraire des spécificités de chaque forme pour avoir des méthodes (ou opérateurs) cohérent.

_J'ai bien évidemment penser en premier lieu au polymorphisme mais cela ne gère que les méthodes identiques pour des objets indépendants entre eux mais construit à partir d'une classe mère virtuelle. Or j'ai des objets dépendants... par construction.
_Je pourrais rajouter un héritage commun (FORME) à chacune de ces classes mais cela ne permet rien (c'est rajouter du vent)
_Une solution batarde serait de créer une classe avec un pointeur (void*) et de le métamorphoser en fonction du véritable objet... c'est une mascarade.
_Je pourrais aussi abandonner l'idée de classe générique mais cela est pourtant tellement clair et évident qu'il doit bien y avoir une solution simple et efficace... mais p-ê sortir du C++ qui ne le peut peu être pas.

Merci d'avance pour vos conseils avisés.

Bonjour,

Citation:

---

Envoyé par DEVfan

_J'ai bien évidemment penser en premier lieu au polymorphisme mais cela ne gère que les méthodes identiques pour des objets indépendants entre eux mais construit à partir d'une classe mère virtuelle. Or j'ai des objets dépendants... par construction.

---

en quoi le polymorphisme t'empêche les dépendances par construction???Une class mère FORME qui contient une liste de FORME. Ca ressemble as ce que tu veut faire non?

Citation:

---

_Je pourrais rajouter un héritage commun (FORME) à chacune de ces classes mais cela ne permet rien (c'est rajouter du vent)

---

Si ce n'est pas pour faire du polymorphisme, je ne voit ce que tu veut faire

Citation:

---

_Une solution batarde serait de créer une classe avec un pointeur (void*) et de le métamorphoser en fonction du véritable objet... c'est une mascarade.

---

Oula ca ca ne parait pas terrible du tout. Du moins en C++

Citation:

---

_Je pourrais aussi abandonner l'idée de classe générique mais cela est pourtant tellement clair et évident qu'il doit bien y avoir une solution simple et efficace... mais p-ê sortir du C++ qui ne le peut peu être pas.

---

Ou cloche ton raisonnement??

Salut,

Comme ca en survolant j'ai l'impression que tu pourrais jeter un oeil au design pattern composite.
L'exemple n'est pas forcement transcendant je trouve (et c'est du java mais c'est un detail ca) mais ca donne l'idee, tu peux chercher sur google pour plus d'information.

MAT.

ah... bon faut que je revoie des bases alors!! (Ou du moins que je regarde le pb sous un autre angle)... si le polymorphisme est possible avec des classes dépendantes, est-ce que je pourrais avoir un petit exemple?
je souhaite avoir classe FORME, classe A, B, C...
et faire
A a; //dépend de B
B b; //dépend de C
C c; //dépend de rien a priori
FORME F1=a;
FORME F2=b;
FORME F3=c;
FORME F=a+b+c; // et au final stocké en tant que FORME sous le format A,B ou C suivant le plus adapté (disponible avec un test)
... et cela ressemble fort à ce que propose Mat007.




Concernant Composite... dans l'idée c'est ça sauf qu'en fait pas comme je l'ai posé. En remplaçant les "implements" par de l'héritage, c'est comme du C++ par contre effectivement.

Le seul hic c'est que le ArrayList..., ça existe pas en C++ (mais p-ê en boost) et surtout ça fait qu'une collecte... comme mon void* proposé... en gros, t'as un objet qui peut être n'importe quoi.

Rappel : mes objets sont DEPENDANTS (objet Z permet d'obtenir l'objet Y qui permet lui-même... etc. qui permet d'obtenir l'objet A... et tout ça par pure agrégation)
Ta solution est de créer une classe ABSTRACTION qui est en gros un pointeur vers un objet quelconque (de A à Z) dans lequel on règle toutes les interactions interclasse.
Cela veut dire redéfinir Cni-Cii méthodes par méthode commune... autrement dit un bon paquet!! Heureusement que j'en ai peu (5,6 classes avec une 20N de méthodes....)!


L'idéal serait en fait de pouvoir s'abstraire du pointeur chiant à gérer et ne définir qu'1 méthode supplémentaire (par méthode commune) pour tenir compte de l'ensemble en s'appuyant sur les dépendances des classes construites... autrement dit si je sais que objet B+ objet C ce fait ainsi, si je construit A à partir de B que je n'ai à rajouter que la nouvelle possibilité objetA+objetB (sinon ça rompt l'encapsulation en plus!!)... et si possible que l'ordre de la relation importe peu (là ça devient impossible à mes yeux!!)

Je n'ai pas forcément bien compris ce que tu souhaites, parler avec des A, B, C n'aide pas trop en terme de conception.

J'ai effectivement pensé au début au pattern composite, comme Mat, mais finalement ta réponse me fait plus penser au pattern decorator.

Salut,
si j'ai bien compris, en gros tu veut faire cela?
(ébauche de code qui marche)

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 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113

#include <iostream> #include <vector> #include <string>   class CForme { public : CForme(){}; CForme (CForme &f) { std::vector<CForme *>::iterator it =f.m_composite.begin(); std::vector<CForme *>::iterator itend =f.m_composite.end(); while(it!=itend) { this->AddComposition(**it); ++it; } }; ~CForme() { std::vector<CForme *>::iterator it =m_composite.begin(); std::vector<CForme *>::iterator itend =m_composite.end(); while(it!=itend) { delete (*it); ++it; } m_composite.clear(); } virtual CForme* GetClone() {return new CForme(*this);};   virtual std::string GetName() {return "CForme";} void print(int niveau =0) { for(int i=0;i<niveau;++i) std::cout<<" "; std::cout<<GetName()<<std::endl; std::vector<CForme *>::iterator it =m_composite.begin(); std::vector<CForme *>::iterator itend =m_composite.end(); while(it!=itend) { (*it)->print(niveau+1); ++it; } } void AddComposition(CForme &f) {m_composite.push_back(f.GetClone());} private : std::vector<CForme *> m_composite; };   class A : public CForme { public : A(){}; A (A &f): CForme(f){}; virtual std::string GetName() {return "A";} virtual CForme* GetClone() {return new A(*this);};   }; class B : public CForme { public : B(){} B (B &f): CForme(f) {}; virtual std::string GetName() {return "B";} virtual CForme* GetClone() {return new B(*this);};   }; class C : public CForme { public : C(){} C (C &f): CForme(f) {}; virtual std::string GetName() {return "C";} virtual CForme* GetClone() {return new C(*this);};   };   int main(int argc, char** argv) {   A a; B b; C c;   c.AddComposition(a); c.AddComposition(b);     CForme F1; F1.AddComposition(a); CForme F2; F2.AddComposition(b); CForme F3; F3.AddComposition(a); F3.AddComposition(b); F3.AddComposition(c);   c.AddComposition(c); CForme F4; F4.AddComposition(c);   F1.print(); std::cout<<std::endl; F2.print(); std::cout<<std::endl; F3.print(); std::cout<<std::endl;   F4.print(); std::cout<<std::endl; return 0; }

---

Ainsi chaque objet peuvent être composé ou non d'sutre objets qui eux même peuvent être composé ou non d'autres objets...

Dans l'hypothèse du pattern composite, je n'aime pas trop l'idée de faire entrer la notion de composite dans la classe de base. J'aurais plutôt une classe Forme sans vector ni rien du tout, et une classe FormeComposite dérivée de Forme qui gérerais cet aspect. Ca ne change rien pour les classes A? B, C, mais permet d'avoir des formes simples, non composites, tout en bas de l'arbre.

Citation:

---

Envoyé par JolyLoic

Dans l'hypothèse du pattern composite, je n'aime pas trop l'idée de faire entrer la notion de composite dans la classe de base. J'aurais plutôt une classe Forme sans vector ni rien du tout, et une classe FormeComposite dérivée de Forme qui gérerais cet aspect. Ca ne change rien pour les classes A? B, C, mais permet d'avoir des formes simples, non composites, tout en bas de l'arbre.

---

Ben c'est la ou je ne comprend pas trop ce qu'il veut.
Si toutes formes peuvent être composé c'est plus comme j'ai fait. Sinon c'est plus ce que tu dit. Et plus propre dans un certain sens. Mais bon ce n'est qu'une ébauche

Merci pour les contributions et effectivement, je crois que je n'ai pas bien énoncé ce que je souhaite.

Soit un type de base (ex : ) char. [je vais faire une analogie avec le langage, ce sera sans doute plus simple]
Je construis une classe qui possède un sens physique et logique comme étant une agrégation de 2 char :

Code:

---

1 2 3 4 5 6 7 8

class Z //cela pourrait s'apparenter à une syllabe (même si l'analogie n'est pas rigoureusement possible...)... ou si on veut une autre analogie à un codon en biologie... un groupe de base. { char c1; char c2;   ... }

---

Puis ensuite une classe qui possède un sens si je la pose ainsi :

Code:

---

1 2 3 4 5 6 7

class Y //cela pourrait s'apparenter à un mot (ou un brin protéinique) { vector<Z> zall; //avec stl...   ... }

---

Ensuite, il me faut encore une classe sensée :

Code:

---

1 2 3 4 5 6 7

class X //cela pourrait s'apparenter à une phrase (ou à une protéine mature) { vector<Y> yall; //avec stl...   ... }

---

et en fait, je peux continuer cette structure à l'infini si je voulais...Tout dépend combien de dimension on veut! (bon ce détail n'est pas utile pour le codage) A ce niveau, on peut remarquer qu'un mot, n'est autre qu'une phrase à 1 seul élément de vector... et ainsi de suite par cascade dès qu'on a qu'un élément. Comme j'ai pris l'analogie des lettres et mots, je souhaiterais pouvoir considérer tous ces objets créés comme du "texte". En effet, un mot, une lettre, une phrase, un paragraphe, etc. ... c'est du texte au final!!
En admettant que je me fixe un certain nombre N de casacade de class de ce type (4 par exemple si je m'arrête au paragraphe), je pourrais donc identifier la classe texte comme étant un objet de la dernière classe... Cependant, lorqu'il s'agit d'un simple mot, pourquoi enregistrer cet objet en tant qu'une bibliothèque à un seul rayon, une seule étagère, un seul livre, un seul chapitre, un seul paragraphe, une seule phrase et un mot?! En soit, pourquoi pas mais je trouve que c'est gaché (surtout si N est grand et que les attributs des classes soient plus sophistiqués). La solution pessimiste est de dire que ce n'est pas à la classe de faire ce boulot... c'est peut-être le cas et alors "Tant Pis!". Mais s'il existe une solution correcte C++, je suis preneur!

...Si jamais, c'est possible, est-ce possible avec un N élvolutif?

Voilà, j'espère que c'est plus clair et merci d'avance de vos réponses.


PS : si le décorateur semble bien correspondre, j'avoue que je sais pas passé de java à C++ là!
[est-ce que je peux rester en C++?]

Citation:

---

Envoyé par DEVfan

Merci pour les contributions et effectivement, je crois que je n'ai pas bien énoncé ce que je souhaite.

---

Bon, avec la description plus détaillée, je reviens vers le composite. Avec 2 saveurs différentes, selon ce que tu veux :

Version 1 : Les classes intermédiaires, on s'en balance.


Pourquoi avoir une classe différente pour une bibliothèque et un rayon ? Tous deux sont simplement des textes, mais aussi des groupes de texte. Et au final, un rayon peut aussi bien contenir des mots que des lettres que des livres.

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

class Text {...}; class Lettre : Texte {...}; class Syllabe : Texte { Lettre l1; // ou Text* l1, selon ce qu'on veut Lettre l2; }; class Collection : Texte { vector<Text*> elements; };   Lettre a; Lettre b; Syllabe s1(a, b); Syllabe s2(a, a); Collection mot1; mot1.add(s1).add(s2).add(s1); Collection mot2; mot2.add(s2).add(s2); Collection phrase; phrase.add(mot1).add(mot2); ...

---

Version 2 : Les classes intermédiaires, c'est important.

Si un rayon ne peut contenir que des livres, un livre que des chapitres... Je partirais alors vers la variante suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Text {...}; class Lettre : Texte {...}; class Syllabe : Texte { Lettre l1; // ou Text* l1, selon ce qu'on veut Lettre l2; }; template <class Element> Collection: Texte { vector<Element*> elements; }; typedef Collection<Syllabe> Mot; typedef Collection<Mot> Phrase; typedef Collection<Phrase> Paragraphe;

---

On garde les mêmes principes (tout reste un texte) mais on impose des relations plus strictes entres les divers éléments de texte.

Citation:

---

Envoyé par DEVfan

PS : si le décorateur semble bien correspondre, j'avoue que je sais pas passé de java à C++ là!
[est-ce que je peux rester en C++?]

---

Le passage n'est en général pas très compliqué en terme d'architecture, toutes les notions de Java se retrouvant en C++ (l'inverse peut être plus complexe). Sur quel point ça bloque ?

J'aime bien la version 2,
mais pourquoi Lettre ,Syllabe et Collection doivent hérité de texte ???
Une class de plus qui pourrai être utile serait
template <class Element,int N> NCollection
{
Element elements[N];// on un vecteur de taille N
};
ainsi
typedef NCollection<char,2> Syllabe;

Citation:

---

Envoyé par Mongaulois

J'aime bien la version 2,
mais pourquoi Lettre ,Syllabe et Collection doivent hérité de texte ???

---

J'ai l'impression que dans la façon dont le texte est construit, DEVfan veut une grande rigueur des types (et donc la dérivation ne sert à rien à ce niveau là), mais que dans la façon dont les différents textes résultants vont être utilisés, dans le code client, il veut pouvoir considérer un texte quelle que que soit sa structure.

Concernant tes solutions :
Euh... tu définis comment la classe Texte qui est manisfestement différente de la classe Text?

Je trouve que ça colle pas... si les objets sont regoupés par l'héritage de la classe Texte, tu ne peux pas manipuler des Textes entre eux. Dans la deuxième version, les termes sont regroupés en style par le template mais c'est tout. Tu es toujours obligé de manipuler les classes. De plus, il faut gérer les croisements comme paragraphe op Syllabe tandis que Syllabe op Paragraphe n'est pas possible. Je souhaite regrouper tous les objets que je peux générer sous une classe représentative de chaque élément comme l'expresso est un brevage.
L'analogie avec le texte s'arrête là parce que si je prends une feuille de papier et que je dessine un triangle puis un cercle... c'est pareil que de faire un cercle et un triangle ou encore de ne faire que le cercletriangle d'un même bloc (si par exemple ils se croisent). Rajouter un livre à un mot, j'avoue que ça fait étrange!
Le triangle, le cercle, le dessin des deux, etc. Tout ça représente la même chose, des Formes enfin c'est le nom que je lui donne ici en tout cas ;) ). Je sais qu'il existe des exemples de polymorphisme pour faire cela. Cependant, une fois qu'un objet est déterminé, il ne peut plus changer de style. Dans ma représentation, on peut dire que j'aurais besoin que ce soit possible (et heureusement j'ai un teste simple pour caractériser mes type d'objet ;) ). En continuant sur les formes, si je prends 2 carrés et que je les place à côté, j'obtient un rectangle. Je souhaiterais donc pouvoir transformer mes 2 carrés en 1 rectangle... je concatène 2 formes en 1. L'information des formes de construction est perdu mais dans mon pb, c'est justement ce que je cherche... toujours avoir le moins de type d'objet. [on peut remarquer que le même rectangle aurait pu être construit avec plein d'autres formes...] Si par contre ensuite, je coupe le rectangle (n'importe comment mais en 2 objets pour l'exemple)... je dois retourner à 2 objets.
Maintenant que j'ai donné un exemple clair (enfin je crois), il faut considérer la FORME (enfin la classe abstraite regroupant tout... la feuille de papier pour continuer l'analogie). Par soucis de sens, je vais l'appeler maintenant une classe TOUT. Cette classe est potentiellement tout : un triangle, un cercle, les 2, collés ou pas, etc. Chaque objet pourrait être défini comme étant un assemblage de rectangle élémentaire, définissant une zone de pixel. J'ai donc une classe rect_de_pixel ; une classe forme_pleine qui est une liste (ou un ensemble) de rect_de_pixel et le TOUT qui est une liste (ou un ensemble) de forme_pleine. [Juste un commentaire : cette façon de faire est un peu idiote mais elle représente bien ce que je cherche].
la rect_de_pixel peut être considérer comme un TOUT mais aussi comme une forme_pleine... ça ressemble à de l'héritage tout simple. Par défaut, je mettrais donc rect_de_pixel hérité par forme_pleine hérité par TOUT. Je suis donc revenu à la case départ... est-il possible d'éviter cela afin d'éviter l'effet "bibliothèque"? [c'est à dire codé un mot en tant qu'1 mot d'un phrase, d'une...., d'une bibliothèque]


Concernant la décoration

Code:

---

1 2 3 4 5

Beverage beverage2 = new DarkRoast(); beverage2 = new Mocha(beverage2); beverage2 = new Mocha(beverage2); beverage2 = new Whip(beverage2);

---

Ca, je trouve très chouette. Bon cela ne veut pas dire que c'est pour mon code mais quoi qu'il arrive c'est un excellent exemple.
Je crois que "extends" est en fait un simple ":" (héritage...).
Par contre, un truc que je trouve étrange... c'est les condiments (comme l'exemple du Mocha)... pourquoi agréger un deuxième brevage alors que ça y est déjà par héritage?

Si j'essaye de coller dessus, je peux dire qu'effectivement le brevage et la FORME ou le texte porte le même rôle : l'objet "ultime" à représenter (TOUT). Sans a priori, tout est dans description. Si l'objet se spécialise, l'information est transmise dans description. Cela se passe bien parce que le type de la description est la même qq soit les brevage et condiment... ce qui n'est pas mon cas. Pour cela, je pense qu'effectivement ce modèle ne peut pas correspondre à ce que je cherche.

As tu regardé le code que j'ai fait?
Je trouve que ca va dans le sens que tu veut. Bien sur faut compléter, mais le principe est la je pense.

oui bien sûr!
La forme du TOUT est une composition de ce que l'on veut et les autres objets sont la même chose avec simplement un nom différent... Je trouve 2 pb : premièrement, autant manipuler uniquement la classe TOUT, les autres n'apportent qu'une description différente que je pourrais obtenir avec 1 méthode Quesuis-je? ; deuxièmement, l'agrégation de pointeur... j'ai comme l'impression que l'on va accumuler les objets sans les simplifier... et en plus, on peut avoir plusieurs manière de représenter une même chose.

Citation:

---

Envoyé par DEVfan

oui bien sûr!
La forme du TOUT est une composition de ce que l'on veut et les autres objets sont la même chose avec simplement un nom différent... Je trouve 2 pb : premièrement, autant manipuler uniquement la classe TOUT, les autres n'apportent qu'une description différente que je pourrais obtenir avec 1 méthode Quesuis-je? ;

---

dans l'exemple oui mais si il y avait une fonction draw(). Elle ne doit pas etre identique pour un cercle un triangle ....

Citation:

---

Envoyé par DEVfan

accumuler les objets sans les simplifier...

---

ah la c'est plus la même chose...

Peut-etre qu'en commencant par determiner ce que tu veux faire avec ces formes ca permettrait d'y voir plus clair.
Le but est quand meme j'imagine d'effectuer des traitements (appeler des methodes) plutot que juste stocker en memoire (organiser des donnees).

MAT.

Concernant le draw, vu la contruction des objets, faire un draw de la classe X revient à faire un draw sur chaque élément Y le composant et ainsi de suite jusqu'à l'élément de base (Z).

Pour les traitements... on peut imaginer faire des intersections de formes (enfin des TOUT qui abstraient la méthode de stockage in fine de l'objet réel), des unions, des complémentaires, des opérations bizarres, etc. L'avantage du TOUT sur les classes X,Y,etc c'est aussi de pouvoir définir des opérations communtatives (A+B=B+A) si l'on souhaite. Faire l'union d'un rect_de_pixel et d'une forme_pleine, ça pose pas de pb conceptuellement mais en pratique, le rect_de_pixel ne connait pas la forme_pleine...

Je cherche donc s'il existe un moyen simple, utile et clair de créer une classe abstraite pouvant manipuler des sous classes construites hiérarchiquement sans pour autant définir ces sous-classes comme des classes du TOUT.

Un exemple :
forme_pleine Union rect_de_pixel donne une forme_pleine (ou un TOUT si en fait, on ne peut pas les simplifier en forme_pleine).
rect_de_pixel Union forme_pleine est réévalué (exemple de l'usage fait éventuellement pour cette classe magique) en forme_pleine (avec seulement 1 rect_de_pixel) Union forme_pleine qui donne la même chose qu'avant.
forme_pleine intersection TOUT peut donner un Z, un rect_de_pixel, une forme_pleine

Autrement dit, lorsque 2 objets sont appelés par hiérarchie inverse, remise à niveau et lorqu'on combine des objets lors d'une opération, le résultat doit être défini dans son type le plus élémentaire.

Bon visiblement, c'est pas possible en tant que classe à part entière (comme je le pensais), mais c'est pas grave. J'ai appris qq constructions marrantes et pour mon appli, je ferais un livre avec peu de chapitre ;)