Discussion :

[Katian]

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 :

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

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

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

[Katian]

merci !

et petite question bete...

puis-je au lieu de

Code :

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

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

faire :

Code :

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

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

[Médinoc]

Je ne vois pas pourquoi tu ne pourrais pas.

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

[koala01]

Salut,

merci !

et petite question bete...

puis-je au lieu de

Code :

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

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

faire :

Code :

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

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

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 :

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

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

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

[Katian]

merci a vous

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