Histoire d'heritage - qualité de code

Version imprimable

Bonjour,

que pensez-vous de ce code ? Je ne l'ai pas compilé, mais il me semble qu'a l'execution, il y a un problème au niveau de la destruction de l'element bo_test

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
class Gel;
 
class Gco
{
	public:
	Gco();
	~Gco();
	void add(Gel *p);
 
	protected:
	Gel* pGel;
}
 
Gco::Gco()
{
}
 
Gco::~Gco()
{
	if(pGel)
             delete pGel;
}
 
void Gco::add(Gel* p)
{
	pGel = p;
}
 
class Gel : public Gco
{
	protected:
	int x;
}
 
class Gbo : public Gel
{
	private:
	int y;
}
 
class Gbu : public Gel
{
	private:
	int z;
}
 
int main()
{
	Gbo* bo_test = new Gbo;
	Gbu* bu_test = new Gbu;
 
	bo_test->add(bu_test);
 
	delete bo_test;
 
	return 0;
}

merci !

07/01/2009, 12h24
ram-0000

Dans le constructeur de Gco, le pointeur pGel n'est pas initialisé à NULL donc si tu construis un objet et le détuis immédiatement, tu fais un delete sur n'importe quoi.

De plus, vu qu'il y a un pointeur dans les membres de la classe, il faudrait peut être/certainement instancier le constructeur de copie et l'opérateur d'affectation (je suis moins sûr pour ce dernier)
07/01/2009, 12h28
Médinoc

En effet, il y a un problème de destruction, car le destructeur est public et non-virtuel.
--> Le destructeur de Gel doit être virtuel.

De plus, comme le dit ram-0000, il faut un constructeur de copie et un opérateur d'affectation explicite: La classe doit soit être parfaitement copiable, soit explicitement non-copiable (constructeur de copie et opérateurs d'affectation déclarés private et non-définis).

De plus, la fonction Add() ne fait pas ce qu'elle dit, vu qu'elle entraine un bug si elle est appelée deux fois.

merci !

et petite question bete...

puis-je au lieu de
Code:

1 2 3 4 5 class Gel : public Gco { protected: int x; }
faire :
Code:

1 2 3 4 5 6 7 class Gel { public: Gco m_gco; protected: int x; }

07/01/2009, 13h13
Médinoc

Je ne vois pas pourquoi tu ne pourrais pas.
07/01/2009, 17h44
3DArchi

Lis donc ces articles :
-> Héritage 1
-> Héritage 2
Tu semble typiquement te poser la question entre IS-A et IS-IMPLEMENTED-IN-TERMS-OF.
09/01/2009, 01h29
koala01
Salut,
Citation:
Envoyé par Katian

merci !

et petite question bete...

puis-je au lieu de

Code:

1 2 3 4 5 class Gel : public Gco { protected: int x; }

faire :

Code:

1 2 3 4 5 6 7 class Gel { public: Gco m_gco; protected: int x; }
Pour faire simple, il faut savoir que la relation d'héritage est la relation la plus forte que tu puisse trouver en programmation orientée objet.

On dit souvent que l'héritage est une relation EST-UN(E) (an IS-A relation)

J'aime à présenter les choses sous la forme de

Citation:

L'héritage (public) se justifie si tu peux sémantiquement dire que l'objet dérivé est un type particulier de l'objet de base

En effet, il est - finalement - très facile de changer une relation EST-UN(E) en une relation du genre de "A-TOUTES-LES-CARACTERISTIQUES-D-UN(E)" qui impliquerait plutôt une agrégation, voire de confondre une relation EST-UN(E) avec une relation du type EST-IMPLEMETE(E)-EN-TERME-DE...

Le principe général (bien qu'il souffre de pas mal d'exception) est donc à la limite de préférer l'agrégation chaque fois qu'il est possible de l'envisager, et de n'utiliser l'héritage que s'il n'y a vraiment pas d'autre solution (entre autre, si tu veux pouvoir faire passer un objet du type dérivé pour... un objet du type de base, voire, faire cohabiter plusieurs objet de types dérivés différents dans une même collections d'objets)

Je m'explique (et l'explication risque d'être un peu plus compliquée :aie):
Un véhicule (générique) pourrait avoir comme états/propriétés le fait qu'il soit en mouvement ou non, la vitesse actuelle l'orientation du déplacement, le sens du déplacement

Il devrait aussi présenter des comportements permettant de modifier la vitesse, l'orientation du déplacement ou le sens du déplacement (sans oublier le fait de s'arrêter complètement)

Si nous n'envisageons de travailler qu'avec des voitures, nous pouvons dire qu'une voiture "a toutes les caractéristiques" d'un véhicule, et donc nous baser sur une agrégation simple, sous une forme proche de
Code:

1 2 3 4 5 6 7 class Voiture { public: Vehicule& getVehicule(); private: Vehicule v; };
Si nous décidons de rajouter des camions, mais qu'un camion ne doit jamais cohabiter dans une collection avec une voiture, nous pouvons rester dans le principe d'une relation "a toutes les caractéristiques de" pour notre camion (et donc fournir une classe camion ressemblant fortement à notre classe voiture).

Si, par contre, tu veux pouvoir utiliser une collection de véhicules sans tenir compte qu'un des éléments de cette collection est spécifiquement un camion ou une voiture, il faudra que la classe camion et la classe voiture dérivent explicitement d'une classe de base identique: la classe Vehicule ;)

Mais, cela implique que, lorsque tu manipulera les éléments de cette collection, tu ne pourra - a priori - utiliser que les méthodes propres... aux véhicules, et que tu ne pourra pas essayer d'accéder à une méthode qui serait, par exemple, propre aux camions (du moins, sans passer par une conversion), et cela, même si les méthodes de la classe Vehicule peuvent adopter un comportement polymorphe.

Evidemment, cela peut impliquer d'avoir une idée relativement précise des besoins réels (voir de l'évolution des besoins) au moment de choisir entre une agrégation et l'héritage ;)
09/01/2009, 18h18
bafman

dans le destructeur de Gco, du delete un pointeur vers un Gel alors que la classe est forward déclaré et non définie. Ca ne va pas marcher.
09/01/2009, 21h34
Katian

merci a vous

koala01, ton explication est très claire ! j'y vois mieux maintenant !