Discussion :

[hpfx]

Bonjour, j'ai une petite question,
voilà, j'ai une classe de base, que j'appelle cbasetruc.

Code :

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

1
2
3
4
class cbasetruc{
public :
long a;
};

Maintenant j'ai deux specialisations de la classe. ctruc1 et ctruc2 (fils de cbasetruc).

Code :

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

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

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

[hpfx]

Super.. merci.

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.

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

[Mat007]

Salut,

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

Là :

Code :

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

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

MAT.

[hpfx]

Salut,


Là :

Code :

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

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 ?

[Mat007]

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.

[hpfx]

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

Ps : l'objectif est la "réutilisabilité" : je ne fait qu'une seule methode qui gere le deplacement..etc...

[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

[Mat007]

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

[hpfx]

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.

[hpfx]

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.

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

[hpfx]

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.

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

[Mat007]

Salut,

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.

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.

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

[nicroman]

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 :

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

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 :

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

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 :

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

1
2
3
4
 
CRenderable
   |--- CMesh
            |--- CAnimatedMesh

La partie de ton code qui s'occupe de l'affichage se fiche de l'objet originel...

[hpfx]

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 :

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

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 :

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
#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 :

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

[hpfx]

Oups j'avais pas vu ta reponse...

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

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 )

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!

[Mat007]

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.