Discussion :

[DEVfan]

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.

[yan]

Bonjour,

_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?

_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

_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++

_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??

[Mat007]

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.

[DEVfan]

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!!)

[JolyLoic]

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.

[yan]

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

Code C++ :

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
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...

[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.