C++ : Heritage multiple mais de même base.

Version imprimable

10/07/2007, 18h42
hpfx

C++ : Heritage multiple mais de même base.
Bonjour, j'ai une petite question,
voilà, j'ai une classe de base, que j'appelle cbasetruc.
Code:

1 2 3 4 class cbasetruc{ public : long a; };
Maintenant j'ai deux specialisations de la classe. ctruc1 et ctruc2 (fils de cbasetruc).
Code:

1 2 3 4 5 6 7 8 9 class ctruc1 : public cbasetruc { public : long b; }; class ctruc2 : public cbasetruc { };
Je crée des objets de type ctruc1 et 2 sans probleme, mais maintenant j'ai besoin de créer une classe ayant les deux specificités, je suis tenté de créer une classe ctruc2 qui herite à la fois de ctruc1 et de ctruc2... (qui heritent dejà de la même classe de base)

est-ce que je peux faire celà ?
y a t'il des precautions a prendre ?

est-ce que tous les compilateurs le prennent en compte ?
D'avance merci...
10/07/2007, 18h51
Lawyer666

Oui tu peux (l'héritage en diamant est autorisé en C++).

Il faut bien penser à déclarer tes héritages virtuels pour ctruc1 et ctruc2 pour éviter la redondance des attributs de la classe cbasetruc.

Il faut aussi vérifier qu'il n'y aura pas de conflits entre les attributs et fonctions de ctruc1 et ctruc2 (vérifie bien les noms de tes membres).
10/07/2007, 18h55
hpfx

Super.. merci.

Citation:

Envoyé par Lawyer666

Il faut aussi vérifier qu'il n'y aura pas de conflits entre les attributs et fonctions de ctruc1 et ctruc2 (vérifie bien les noms de tes membres).

ha ouais, t'as raison ca parait evident, mais il faut faire gaffe.
bien que ctruc1 et 2 ont toute les deux une methode draw, je vais faire aussi une methode draw pour ctruc3 donc ca devrait aller. pour les données membre, c'est bon, tous les noms sont differents.

Citation:

Envoyé par Lawyer666

Il faut bien penser à déclarer tes héritages virtuels pour ctruc1 et ctruc2 pour éviter la redondance des attributs de la classe cbasetruc.

Qu'est-ce que tu veux dire par là ? (je dois le mettre ou le mot "virtual" ?). je rappelle que j'instentie aussi des ctruc1 et ctruc2 hein. (j'en profite pour preciser que ca fait des années que je n'avais pas fait de C++ ;) )
10/07/2007, 19h28
Mat007
Salut,

Citation:

Envoyé par hpfx

Qu'est-ce que tu veux dire par là ? (je dois le mettre ou le mot "virtual" ?).

Là :
Code:

1 2 3 4 5 6 7 8 class ctruc1 : virtual public cbasetruc { }; class ctruc2 : virtual public cbasetruc { };
MAT.
10/07/2007, 21h41
hpfx
Citation:
Envoyé par Mat007

Salut,

Là :

Code:

1 2 3 4 5 6 7 8 class ctruc1 : virtual public cbasetruc { }; class ctruc2 : virtual public cbasetruc { };

MAT.
ha... je ne connaissait pas cette syntaxe là.
mais qu'est-ce que ca va changer pour les classe ctruc1 et 2 ? je peux continuer à les utiliser comme avant ? promis ? ;)
10/07/2007, 23h30
Mat007

Citation:

Envoyé par hpfx

mais qu'est-ce que ca va changer pour les classe ctruc1 et 2 ? je peux continuer à les utiliser comme avant ? promis ? ;)

Il y a quelques subtilités, notamment sur l'ordre de construction/destruction, voir par exemple sur C++ FAQ Lite (j'ai un peu cherché dans la FAQ d'ici mais j'ai trop rien trouvé).

Cela dit les cas d'utilisation sont tout de même assez rares, surtout quand on a la maîtrise des classes (qu'on les écrit ou qu'on peut les modifier), tu es sûr que tu ne peux pas faire autrement ?
(je compte sur les doigts d'une main les fois où j'ai eu recours à ça, et c'était toujours avec des classes virtuelles pures dans le haut du diamand)

MAT.
11/07/2007, 22h57
hpfx

Citation:

Envoyé par Mat007

tu es sûr que tu ne peux pas faire autrement ?
MAT.

Mon exemple concret :
projet : une sorte de clone de mario bross. (voir forum sdl sources dispo)
classe de base : baseItem (données membre : coordonnées x;y)
classes de "premiers niveaux":
-ItemDepl (possede des methodes qui gere le deplacement)
-ItemZone (possede des methodes capables de "capter" le passage dans une zone)

maintenant, pour un bloc cachéqui doit apparaitre lors quand on le heurte, j'instincie un ItemZone.

pour un bonus (champignons) je créer une classe ItemBonus qui dérive à la fois de ItemDepl et de ItemZone (les champignons se déplacent, tombent etc...)
Mon bonus est donc une instance de ItemBonus.
Un enemi est aussi un objet qui sera instancié d'une classe qui derivera de plusieurs classe tel que ItemZone et ItemDepl.

Mais il faut noter que j'aurai besoin d'instancier des objet de classe de "premier niveau"

au stade de ma réflexion, je ne sais pas si j'aurai besoin de faire dériver une classe de 3 classes 8O

Ps : l'objectif est la "réutilisabilité" : je ne fait qu'une seule methode qui gere le deplacement..etc...
11/07/2007, 23h16
Alp

Ton ItemBase correspond à une classe de coordonnée, non?

N'oublies pas que l'héritage public symbolise la relation EST-UN. Un perso est-il un couple de coordonnées ? Je ne le vois pas comme ça. Cependant un perso possède des coordonnées... Dans pas mal de cas, on peut remplacer l'héritage public par la composition (au lieu d'hériter, on met une instance de la classe de base dans la classe dérivée). C'est ton cas ici.

Lis donc ceci : http://www.gotw.ca/gotw/014.htm
11/07/2007, 23h20
Mat007

Citation:

Envoyé par hpfx

classe de base : baseItem (données membre : coordonnées x;y)

Cette classe n'a aucune méthode ?
C'est quoi l'intérêt d'en dériver plutôt que de l'aggréger ?

MAT.
edit : crap trop lent :)
11/07/2007, 23h35
hpfx

Citation:

Envoyé par Mat007

Cette classe n'a aucune méthode ?
C'est quoi l'intérêt d'en dériver plutôt que de l'aggréger ?

si elle a deux methodes (en plus d'une methode virtuelle pure "virtual void draw()=0")
ces deux methodes sont :
bool isdead() (est-ce qu'on a plus besoin de cet item, j'ai prevu un garbage collector, comme je compte faire pas mal d'item en dynamique, par exemple un "tir" est un item)

bool valid(Uint x,Uint y) (cet item est-il valide, peux ton l'activer. par exemple on passe un enemi en mode actif si on s'en approche, en gros on va dire que valide(..) calcule la distance par rapport au bloc et si elle est inf à une certaine valeur on renvoie true)

il y en aura peut être d'autre... pour l'instant c'est une reflexion.
11/07/2007, 23h39
hpfx

Citation:

Envoyé par Alp

Un perso est-il un couple de coordonnées ?

ben pour moi, une donnée membre corresponds a une caractéristique, et donc un perso possede comme caracteristique des coordonnées.
Bon bref, c'est un point de detail, je joue sur les mots ;)

mais par contre.. imaginons que je soit interressé par cette agregation, je supprime ma classe de base, et j'ai des coord dans ItemZone et encore des coord dans ItemDepl.
et si maintenant je crée une classe multi-dérivé (mais plus en diamant du coup) ben j'aurai DEUX coordonnées (deux x et deux y) c'est justement ce que je veux éviter.
12/07/2007, 00h04
Alp

Tu n'as qu'à moitié compris ce que l'on a voulu te dire ...
Un caractéristique est un attribut, ce n'est pas une classe mère, alors pourquoi dériver ta classe de coordonnées? Ca doit être un attribut!

Penses tu qu'un ennemi est un Déplacement? Non, il possède des déplacements. On peut le déplacer, mais lui-même n'est pas un déplacement, ni une zone. Il possède une zone.
L'héritage est la solution de facilité qui permet d'éviter des lignes. Seulement cela ralentit le programme à l'exécution et cela entraine des erreurs de conception énormes. Lis bien le lien que je t'ai donné, si tu comprends l'anglais.

Tu vois ce que l'on veut te dire désormais ?
12/07/2007, 09h46
hpfx

Citation:

Envoyé par Alp

Tu n'as qu'à moitié compris ce que l'on a voulu te dire ...

Bon, je vais essayer de comprendre, mais c'est pas facile justement.
sinon tu as raison : un enemi n'est pas un deplacement.
Pour moi, c'est en quelquesorte un moyen de factoriser du code (qui est lourds : demi tour en presence de bloc au même niveau, tomber s'il n'y a rien de solide etc...).
Mais bon, jusqu'a present (on vera apres) pour moi ca reste surtout une question de vocabulaire, j'aurai pu nomer ma classee : Objet_Pouvant_se_deplacer c'est juste un peu plus long ;)

Bon je vais essayer de comprendre ce doc, mais je veux une solution ou je n'ai pas besoin de duppliquer du code.
Merci.
12/07/2007, 09h53
Alp

Ca factorise du code mais ça ralentit à l'exécution (alors qu'on pourrait faire autrement) et même, à la réflexion, tu te rendras compte que réellement il y a un petit défaut de conception sous-jaccent.
12/07/2007, 10h12
Mat007

Salut,

Citation:

Envoyé par hpfx

j'aurai pu nommer ma classe : Objet_Pouvant_se_deplacer c'est juste un peu plus long

Oui, ça c'est comment les autres éléments du système, les autres objets qui vont manipuler les objets de cette classe, la perçoivent.
Mais c'est relativement séparé (ou séparable en tous cas) de la manère dont c'est implémenté et les autres éléments du système n'ont pas du tout besoin de savoir qu'il y a un x et un y dedans.
Par exemple il leur suffit de savoir qu'il existe une méthode MoveTo( x, y ) et c'est tout.

Je ne suis pas vraiment persuadé que les performances fassent partie des arguments clefs, il est toujours temps de se poser cette question plus tard...
Par contre avoir un système souple car composé d'objets de classes bien découplées les unes par rapport aux autres c'est quand même plus important.

Citation:

Envoyé par hpfx

je veux une solution ou je n'ai pas besoin de duppliquer du code.

C'est pas du code que tu dupliques mais des données, c'est quand même différent :)
Pourquoi ne pas créer une classe Coordonnées qui encapsule x et y par exemple ?

MAT.
12/07/2007, 10h19
Alp

Oui comme l'a dit Mat007, il y a autre chose de très important : la flexibilité du code. Moins tes classes sont dépendantes les unes des autres, plus facilement tu pourras modifier le code d'une classe, en rajouter une, en remplacer une, etc ... Maintenir ton code sera d'autant plus facile quand tes classes auront juste une faible lien(composition) contrairement à l'héritage public qui est le lien le plus fort.

Je pense que tu confonds réutilisation de code, et polymorphisme...

Essaye de reflechir en pur orienté-objet et non en C++. L'adaptation au C++ se fera tout seul après.

Comme j'ai pas beaucoup d'information sur ce que tu cherches à obtenir, je ne peux faire qu'un guess, mais bon, je dois pas être très loin...

Le développeur C++ fait un truc genre:
Code:

1 2 3 4 5 6 7 8 9 10 CGameObject |--- CRenderableObject (peut être déssiné) | |--- CPhysicalObject (peut être déplacé dans le monde) | | |--- CAnimating (peut être animé) | | |--- CDoor | |--- CCollectableObject (peut être mis dans un inventaire) | |--- CWeapon | |--- CTeapot |--- CSpawnPoint
Et maintenant on lui dit: l'arme, elle doit être animée... le premier reflexe est de bouger l'arme dans CAnimating... mais elle n'est plus collectable.
Alors bouger CCollectableObject dans CAnimating ? Même la teapot devient animée...
Le développeur C++ se retrouve donc à faire de l'héritage multiple...

Maintenant, version du développeur 'objet':
Code:

1 2 3 4 5 6 7 8 9 CGameObject (IRenderable* getRenderable(), IAnimation* getAnimation()) |--- CPhysicalObject | |--- CDoor | |--- CCollectableObject | |--- CWeapon | |--- CTeapot |--- CLogicObject |--- CSpawnPoint
Chaque objet est une représentation "physique" (au sens dans la vraie vie) de ce qu'il représente. Le fait qu'on puisse l'afficher, ou qu'il soit animé n'est qu'un des "behavior" de l'objet, et ne doit pas filtrer dans l'héritage.

Une bonne facon de voir les choses, est de se limiter en module... Quel est le minimum d'information nécessaire pour gérer le monde que tu veux représenter ? Ce qui exclut l'affichage (pas besoin d'affichage pour gérer), donc encore mieux l'animation, ....
Ensuite, rajoute par association (hors héritage donc) les bouts dont tu as besoin.... Ces bouts ne sont pas forcément des interfaces (comme je l'ai écris dans mon exemple) et peuvent avoir leur propre héritage comme:
Code:

1 2 3 4 CRenderable |--- CMesh |--- CAnimatedMesh
La partie de ton code qui s'occupe de l'affichage se fiche de l'objet originel...

Bon, laissons quelques instant de coté cette discussion interressante (*)
pour un petit exemple.
voici un test complet, mininal et le plus simple possible d'implementation de classes en diamant, au cas ou qq d'autre que moi serait interressé.

Code:

1
2
3
4
5
6
7
8
9
 
A1,X1,Y1 et Z1 forment le diament.
A1,B1 est un heritage tout simple, pour comparaison
 
   A1   |  A1
  /  \  |    \
 X1  Y1 |    B1
  \  /  |
   Z1   |

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
#include <iostream.h> // cout
 
class A1 
{
public:
	int x; // donnée membre.
	A1()		{ cout<<"A1 constr def"<<endl;}
	virtual ~A1()	{ cout<<"A1 destr"<<endl; }
};
 
 
class B1 : public A1
{
public:
	B1() {cout<<"B1 constr def"<<endl;}
	virtual ~B1()	{ cout<<"B1 destr"<<endl; }
	void doit() {cout<<"B1 just do it... "<<x<<endl;}
};
 
 
class X1 : virtual public A1
{
public:
	X1() {cout<<"X1 constr def"<<endl;}
	virtual ~X1()	{ cout<<"X1 destr"<<endl; }
	void doit() {cout<<"X1 just do it... "<<x<<endl;}
};
 
 
class Y1 : virtual public A1
{
public:
	Y1() {cout<<"Y1 constr def"<<endl;}
	virtual ~Y1()	{ cout<<"Y1 destr"<<endl; }
};
 
 
 
class Z1 : public X1, public Y1
{
public:
	Z1() {cout<<"Z1 constr def"<<endl;}
	virtual ~Z1()	{ cout<<"Z1 destr"<<endl; }
 
};
 
int main( int argc, char* args[] )
{
	cout<<"--- test Z1 --- en diamant"<<endl;
	Z1 *p=NULL;
	p = new Z1;
	p->x=2;
	p->doit();
	delete p;
	cout<<"--- test B1 --- heritage simple"<<endl;
	B1*q=new B1;
	delete q;
	cout<<"--- test X1 --- heritage avec virtual"<<endl;
	X1*r=new X1;
	delete r;
return 0;
}

et le plus important, la sortie std :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
--- test Z1 --- en diamant
A1 constr def
X1 constr def
Y1 constr def
Z1 constr def
X1 just do it... 2
Z1 destr
Y1 destr
X1 destr
A1 destr
--- test B1 --- heritage simple
A1 constr def
B1 constr def
B1 destr
A1 destr
--- test X1 --- heritage avec virtual
A1 constr def
X1 constr def
X1 destr
A1 destr

voilà.

(*) même si tu as sans doute raison a propos du bug de conception, je ne peux pas discuter la dessus car j'ai pas ton niveau. il en reste que je ne partage pas ton avis sur la question de performance :
pour moi C++=> genericité => gain de temps à la conception. si c'est pas optimisé, c'est la faute du compilo, pas du language.

12/07/2007, 11h04
hpfx

Oups j'avais pas vu ta reponse...

Citation:

Envoyé par nicroman

Je pense que tu confonds réutilisation de code, et polymorphisme...

Ouais sans doute...
J'ai lu avec plaisir ton exemple car c'est tres concret.
et..

Citation:

Envoyé par nicroman

Une bonne facon de voir les choses, est de se limiter en module...

C'est là que ca devient plus compliqué (en fait tout est clair jusque là, et je croyai peut être que tu allais me donner une methode magique ;) )

Citation:

Envoyé par nicroman

Ensuite, rajoute par association (hors héritage donc) les bouts dont tu as besoin....

Aïe ! c'est donc ca encore... des associations...
c'est a dire copier/coller des bouts de code existant dans d'autres classes, c'est bien celà ?

en tout cas merci pour ton exemple, super!
12/07/2007, 11h14
Mat007

Citation:

Envoyé par hpfx

Aïe ! c'est donc ca encore... des associations...
c'est a dire copier/coller des bouts de code existant dans d'autres classes, c'est bien celà ?

Non, si tu aggrèges une classe Coordonnées (par exemple) tu ne copies pas le code, au contraire tu le factorises dans cette classe.
Par contre oui, toutes les classes qui ont besoin de manipuler les Coordonnées vont devoir d'une façon ou d'une autre obtenir (voire conserver) une référence sur une instance de cette classe.

Si tu aggrèges c'est un peu comme si tu mettais une articulation entre deux objets : ça peut bouger, ça se démonte facilement, tu peux intercaler d'autres objets entre les deux tant que le mécanisme de fixation est compatible, etc..
Si tu dérives tu soudes les deux objets ensemble.

Après, c'est un choix :)

MAT.
12/07/2007, 11h20
hpfx

Citation:

Envoyé par Mat007

vont devoir d'une façon ou d'une autre obtenir (voire conserver) une référence sur une instance de cette classe.

Donc si j'ai bien compris (et je te jure que je fais un effort hein)
prenons le bon exemple de nicroman
le CWapon de l'exemple, on le laisse deriver de CCollectableObject uniquement.
Mais pour lui ajouter la caracteristique "animé", on crée une instance d'un CAnimated que l'on met en donnée membre ? (pour en garder une reference)
C'est bien ca ?

Citation:

Envoyé par Mat007

Si tu aggrèges c'est un peu comme si tu mettais une articulation entre deux objets : ça peut bouger, ça se démonte facilement, tu peux intercaler d'autres objets entre les deux tant que le mécanisme de fixation est compatible, etc..
Si tu dérives tu soudes les deux objets ensemble.

c'est compliquer les metaphore là, il me faut du concret si tu veux que je comprenne ;) :aie:
12/07/2007, 11h34
Alp

Si si elle est très bonne tu vas comprendre!

Tu as (dans la vraie vie, pas dans ton IDE) deux objets A et B soudés l'un à l'autre. Imaginons que tu veuilles rajouter un petit objet à l'extrémité de B qui est collée à A, tu fais comment? Tu peux pas c'est soudé.
Le dessin qui va avec : (le X est la soudure)

Citation:

<--------X------------>
B A

Ca c'est le lien qu'il y a entre une classe mère et sa dérivée.

On voit bien que tu ne peux rien mettre. Par contre, si A et B sont liés par un mécanisme déformable, souple, etc ... on compare donc ici à la composition, cela donne plutot cela :

Citation:

<-------->O<------------>
B A

O désigne le mécanisme très souple qu'on peut détacher, remettre.
Donc si on veut par exemple rajouter un bout C à l'extrémité droite de B, on peut, cela donne ceci :

Citation:

<--------><-->O<------------>
B C A

De plus A n'y verra que du feu car tout ce que A peut voir c'est le mécanisme de liaison flexible qui est en fait la composition .

Ca va mieux ?
12/07/2007, 11h35
hpfx

Citation:

Envoyé par Mat007

Par exemple il leur suffit de savoir qu'il existe une méthode MoveTo( x, y ) et c'est tout.

juste une remarque qui n'a peut être pas d'importance,
non ma classe n'as pas de MoveTo(), on ne le dit pas ou elle doit aller. c'est elle qui decide de son mouvement, elle a juste une methode depl(), un "ticks", on lui envois ce "deplace toi" quand c'est a son tour (boucle principal du jeu).

D'ailleur, moi mes x et y sont encapsulés justement, il n'est pas question que ca soit géré en dehors... qui parlait de "bug de conception" ? ;)
bon c'est bas ce que je viens de dire, tu ne connais pas mon projet, tu ne pouvais pas savoir.
Par contre j'attends de voir un exemple concret avec le CWapon et cette histoire d'agregation, je suis vraiment interessé.
12/07/2007, 11h42
hpfx

Citation:

Envoyé par Alp

Si si elle est très bonne tu vas comprendre!
Ca va mieux ?

Ben... pour te montrer ce que je comprends (pas).. disons que ton C est un bout de code, bon ben je ne vois pas en quoi avec une classe dérivé tu ne peut pas rajouter une methode (C) dans la classe de base ?
Bon, et puis si C n'est pas du code mais des données, ben c'est pareil, je ne vois pas de soucis.

tu vois avec les metaphore c'est pas gagné.

Mais je suis friand d'exemple, celui nicroman est super. i la bien decrit ce qu'il ne fallais PAS faire, mais c'est vague pour moi sur ce qu'il faut faire...
et donc j'ai juste une question a ce propos que je recopie ici :

Citation:

le CWapon de l'exemple, on le laisse deriver de CCollectableObject uniquement.
Mais pour lui ajouter la caracteristique "animé", on crée une instance d'un CAnimated que l'on met en donnée membre ? (pour en garder une reference)
C'est bien ca ?
12/07/2007, 11h42
nicroman

Citation:

Envoyé par hpfx

Donc si j'ai bien compris (et je te jure que je fais un effort hein)
prenons le bon exemple de nicroman
le CWapon de l'exemple, on le laisse deriver de CCollectableObject uniquement.
Mais pour lui ajouter la caracteristique "animé", on crée une instance d'un CAnimated que l'on met en donnée membre ? (pour en garder une reference)
C'est bien ca ?

Absoluement....

Après il y aura toujours des cas alambiqués comme Carré - Losange - Rectangle - Parrallelogramme....
Un Carré est un Losange et un Rectangle
Un Losange est un parallelogramme
Un Rectangle est un parrallelogramme
12/07/2007, 11h54
Alp

Non C n'est ni une donnée ni une fonction.
A et B ont une relation. Chez toi c'est l'héritage, nous on te conseille la composition.
Si on veut mettre une classe C entre A et B dans la relation, ca serait dur de le faire par l'héritage, enfin en tout cas tu vois qu'il faudra modifier pas mal de code et ça restera _rigide_ . Enfin, je laisse nicroman t'expliquer alors :aie:
12/07/2007, 12h13
hpfx
Citation:

Envoyé par nicroman

Absoluement....

Ok, merci baucoups.

Bon, alors je resume.
Là ou moi j'aurai crée une classe supplementaire CAnimWapon qui aurait dérivé à la fois de CAnimated et de CWapon (donc on se retrouve en diaman).
Et bien vous, vous créez un membre de CWapon, disons mAnim.

ok.
c'est plus simple a maintenir ? sans doute.
mais par contre, moi j'ai quand même un probleme :
1er probleme.
pour faire reference a mon projet, disons que j'ai des Wapon qui sont animated et des Wapon qui ne le sont pas (des enemis qui bougent et qui ne bouge pas, des plantes carnivores si vous preferez)

disons qu'il existe une methode draw() (ou render() peu importe le nom qu'on lui donne) cette fonction est en charge de dessiner l'objet.
moi de mon coté j'appelle p->draw() et hop la magic du C++ (le polymorphisme?) fait que le bon draw est appellé (celu ide cWapon ou celui de CanimWapon)
mais vous avec votre systeme ?
vous appeller p->draw(); de CWapon...
dans lequel vous avez un IF ou un SWITCH qui en fonction du type d'objet (ha oui tiens un membre supplementaire) et vous faites :
Code:

1 2 3 4 5 6 7 8 CWapon::draw() { if (mIsAnimated) mAnim.draw(); else { // le draw dans le cas ou c'est pas animé } }
moi je ne trouve pas celà bien.
d'ailleur je cite ici : http://www.parashift.com/c++-faq-lit....html#faq-25.4

Code:

Use inheritance only if doing so will remove if / switch statements from the caller code

que je traduit par : l'heritage c'est pas mal pour eviter des if/switch.. (c'est logique car c'est une "specialisation" on le rends plus précit, plus specialisé, il est animé, s'il fallait gerer toutes les specialité dans une seule classe on aurait une tone de If/switch)

2eme probleme.
il y a plein de parametre qui faudra sans cesse synchroniser entre la classe CWapon et ses "agragation" (objet membre)
de temps en temps il faudra lui dire que ses coordonnées ont changé (peu importe comment si c'est un objet a part ou si c'est 2 variable x et y)
i lfaudra :
Code:

1 2 3 4 5 mAnim.x=x; mAnim.y=y; // ou alors, peu importe mAnim.setCoord(mCood);
mais il peu y avoir d'autre parametre (cycle de vie de l'objet par exemple...)
Bref des données qui existe dans les classe CAnim et CWapon et qu'il ont en commun (que se soit par derivation d'une classe de base ou pas!) CAnim a besoin de coordonnées pour animer des objet qui sont instancié directement (est-ce un bon exemple?) et Cwapon aussi...
j'utilise le cycle de vie (status=dead) par exemple pour ne pas faire de rendu grapfique si l'objet n'existe plus...

avec la derivation en diaman, non seulement il n'y a pas besoin de les synchroniser, mais en plus il n'y a pas de redondance, car il n'y a qu'une seule variable !

voilà.
alors, qu'en pensez vous ? est-ce que je me plante ? est-ce bien celà l'agregation ? les probleme que je vois sont ils contournablent, sont'ils acceptablent pour vous ? ou n'existent pas car vous faites autrement ?
12/07/2007, 12h39
Mat007
Citation:
Envoyé par hpfx

dans lequel vous avez un IF ou un SWITCH qui en fonction du type d'objet (ha oui tiens un membre supplementaire) et vous faites :

Code:

1 2 3 4 5 6 7 8 CWapon::draw() { if (mIsAnimated) mAnim.draw(); else { // le draw dans le cas ou c'est pas animé } }

moi je ne trouve pas celà bien.
Tu fais bien :)
En fait CWeapon::draw se contenterait de faire :
Code:

1 2 3 4 5 CWapon::draw() { mAnim.draw(); }
Et c'est le CAnimation qui se débrouillerait.
Du coup on voit bien à quel niveau se situe la souplesse : il suffit de construire CWeapon en lui passant une différente implémentation de CAnimation pour, sans changer autre chose, modifier son comportement vis à vis du reste du système.
Citation:
Envoyé par hpfx

il y a plein de parametre qui faudra sans cesse synchroniser entre la classe CWapon et ses "agragation" (objet membre)
de temps en temps il faudra lui dire que ses coordonnées ont changé (peu importe comment si c'est un objet a part ou si c'est 2 variable x et y)
i lfaudra :

Code:

1 2 3 4 5 mAnim.x=x; mAnim.y=y; // ou alors, peu importe mAnim.setCoord(mCood);
Si tout le monde a une référence sur le même objet Coordinate il sera mis à jour pour tout le monde à la fois.
Si c'est une notification de mise à jour qu'il faut (pour déclencher des traitements uniquement en cas de modification) il faudra sans doute s'intercaler quelque part dans l'appel de méthodes qui va mener à la modification des données x et y : c'est quand même plus facile avec un 'setCoord'.
Et de nouveau on voit que l'aggrégation apporte une solution plus souple en permettant de plus facilement intercaler des objets.
L'alternative est de dériver pour réimplémenter la méthode 'setCoord', y écrire un traitement spécifique, puis rappeler la 'vraie' méthode 'setCoord'.
Oui mais c'est laquelle la 'vraie' méthode 'setCoord' dans une hiérarchie avec de l'héritage multiple partout ?

MAT.

Bon... je vais essayer d'extraire une classe de mon moteur pour prendre un exemple concret:

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
 
class Resource : public SmartData
{
protected:
   virtual  void load(inputstream is)
   {
        /* ici on va 'charger' le renderable. Donc: lire la classe, instancier un objet de cette classe là, et 'charger' le renderable a partir d'autre resources. */
   }
};
 
class Object : public Resource
{
private:
 
public:
   /* n'importe quoi nécessaire à la gestion des objets, genre getId(), ... */
 
protected:
   virtual  void loadState(inputstream id)
   {
        /* ici on récupère d'un save-game l'état de l'objet au moment du save. */
   }
 
   virtual  void saveState(outputstream id)
   {
        /* ici on serialise l'état de l'objet. */
   }
};
 
 
class ObjectBehavior : public Resource
{
    /* histoire de récupérer un objet à partir du behavior. */
    Object*   getObject();
};
 
class PhysicalBehavior : public ObjectBehavior
{
    /* abstraction du moteur physique. permet aussi de récupérer la position/vitesse de l'objet à tout moment. */
    WorldPosition    getPosition();
    WorldSpeed      getSpeed();
};
 
class RenderingBehavior : public ObjectBehavior
{
    /* abstraction du moteur graphique. permet aussi de dessiner l'objet (méthode "Draw()"). */
     void    Draw();
};
...

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
 
 
class WorldObject : public Object
{
   /* virtuellement tous les objets peuvent être 'renderable'. Le lien vers renderable se fait au load. */
    SmartPtr<RenderingBehavior>   mRendering;
    /* Un pointeur vers un 'physicalObject'. Le PhysicalObject. */
    SmartPtr<PhysicalBehavior>   mPhysics;
public:
    inline PhysicalBehavior*  getPhysicalBehavior() const
    { return mPhysics; }
 
   inline RenderingBehavior*  getRenderingBehavior() const
   { return mRendering; }
 
protected:
   virtual void load()
    { /* chargement du rendering-behavior et du physical-behavior des resources. */ }
};
 
class CollectableItem: public WorldObject
{
    SmartPtr<InventoryBehavior>   mInventory;
public:
    inline InventoryBehavior*  getInventoryBehavior() const;
    { return mInventory; }
 
protected:
   virtual void load()
    { /* chargement du inventory-behavior des resources. */ }
};
 
 
class EquipableItem : public CollectableItem
{
    SmartPtr<CharacterBehavior>   mCharBehavior;
public:
    inline CharacterBehavior*   getCharacterBehavior() const
    { return mCharBehavior; }
};
 
class UsableItem : public EquipableItem 
{
    SmartPtr<SkillUsageBehavior>    mSkillUsage;
public:
    inline SkillUsageBehavior*  getSkillUsageBehavior() const
    { return mSkillUsage; }
};
 
...

Ca c'est la partie 'world management'... Le truc qui va gérer la durée de vie des objets....

Maintenant, on veut dessiner des objets... c'est facile (pseudocode):

Code:

1
2
3
4
 
foreach Object obj in list
    if (obj.getRenderingBehavior())
        obj.getRenderingBehavior().draw();

On veut les afficher dans l'inventaire ? L'inventaire est composé de CollectableItems:

Code:

1
2
3
4
 
foreach CollectableItem it in list
    if (it.getInventoryBehavior())
        it.getInventoryBehavior().displayImage()

Maintenant je peux tres bien faire en sorte qu'une "porte" spéciale du jeu puisse être mise dans l'inventaire sans toucher un seul bout de code ! Il suffit que je lui associe l' inventory-behavior adapté.

Ainsi, on peut changer simplement par les resources comment une armure va influer sur le personnage. Voir animer l'armure si on a envie....

Le meileur exemple étant sur les miroirs / doorway / portals.

Un 'portal' est un objet spécial qui permet de changer de zone quand on le franchit.
Un miroir est un simple objet du monde.
Et pourtant, les deux utilisent le même rendering-behavior: PortalRendering qui permet de voir une autre zone (ou la même) sous un autre angle (ou le même).