Question sur l'héritage multiple

Version imprimable

12/08/2010, 18h07
paparasta

Question sur l'héritage multiple
Bonjour,

Voici mon schéma de classe cible :
Code:

1 2 3 4 5 6 A / \ B C \ / \ D E
Afin d'avoir un A unique au niveau de D, j'ai recours à de l'héritage virtuel :

Class A
Class B : public virtual A
Class C : public virtual A
Class D : public B, C
Class E : public C

Du coup au niveau de E, j'ai des pbs de compilation, notamment au niveau du constructeur où j'initialise la mère (C) ; il me dit qu'il faut aussi que j'initialise A.

>> error C2512: 'A::A' : no appropriate default constructor available

Pourriez-vous me conseiller sur ces déclarations de classes au vu de mon schéma cible ? Merci
12/08/2010, 18h34
NoIdea

Il me semble que ce devrait être D qui hérite virtuellement de B et C et non B et C qui héritent virtuellement de A. Il faut dire que je n'ai jamais encore eu de structure en diamant et donc n'est jamais eu recours a l'héritage virtuel. Un conseil : vérifie.
12/08/2010, 18h54
3DArchi

Salut,
Cela est lié à l'ordre d'appel des constructeurs : F.A.Q. : Dans quel ordre sont construits les différents composants d'une classe ?
Ta classe A ne doit pas avoir de constructeur par défaut mais uniquement des constructeurs avec paramètres. Il faut donc préciser au niveau de D quel constructeur tu souhaites appeler (ceux préciser au niveau B et C ne sont pas pris en compte, logique puisque tu veux qu'une seule instance de A par l'héritage virtuel et donc tu dois préciser comment construire cette instance) :

Code:

A::A(...):D(...),B(..),C(..)..{...}
12/08/2010, 19h02
koala01

Salut,

Citation:

Envoyé par 3DArchi

Code:

A::A(...):D(...),B(..),C(..)..{...}

Tu as du confondre, c'est

Code:

D::D(...):A(...),B(...),C(...{}

C'est D qui hérite de B et de C et ces deux derniers qui héritent de A :D
13/08/2010, 05h53
3DArchi

Citation:

Envoyé par koala01

Salut,
Tu as du confondre, c'est

Code:

D::D(...):A(...),B(...),C(...{}

C'est D qui hérite de B et de C et ces deux derniers qui héritent de A :D

Oui.Merci pour la rectification.

OK merci je comprends mieux.
Par contre du coup je trouve ca infernal de devoir répéter sur chaque
sous-classe l'initialisation de A.

Voyez-vous une meilleure façon de procéder ?

Voici un exemple complet :

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
63
64
65
66
67
68
69
70
71
72
73
74
75
//      A 
//     / \
//    B   C
//     \ / \
//      D   E
//      |
//      F
 
class A
{
    public:
        int i;
        A( int j );
};
A::A( int j )
{
}
 
class B : public virtual A
{
    public:
        B( int j );
};
B::B( int j ) : A( j )
{
}
 
class C : public virtual A
{
    public:
        C( int j );
};
C::C( int j ) : A( j )
{
}
 
class D : public B, public C
{
    public:
        D( int j );
};
D::D( int j ) : C( j ), B( j ), A( j )
{
}
 
class E : public C
{
    public:
        E( int j );
};
E::E( int j ) : C( j ), A( j )
{
}
 
class F : public D
{
    public:
        F( int j );
};
F::F( int j ) : D( j ), A( j )
{
}
 
int main(int argc, char* argv[])
{
 
    A a( 1 );
    B b( 2 );
    C c( 3 );
    D d( 4 );
    E e( 5 );
    F f( 6 );
 
	return 0;
}

13/08/2010, 09h47
koala01

De manière générale, lorsqu'un héritage multiple fini en "losange de la mort", c'est souvent le symptôme d'un problème de conception à la base.

Peut être devrais tu déjà te poser la question de l'opportunité réelle de faire hériter B ET C de a et / ou de faire hériter D de B ET de C :question:

Il ne faut, en effet, pas oublier que l'héritage public représente une relation EST-UN et qu'il n'a donc de sens que si tu peux, effectivement, dire en toute bonne fois en respectant la sémantique qu'un objet du type dérivé EST-UN objet de la classe de base.

Le principe de substitution de Liskov te permet d'apporter une partie de la réponse à cette question ;)

Mais il est particulièrement difficile de juger de l'opportunité d'un héritage lorsque l'on parle d'un cas trop abstrait, car elle doit s'évaluer... au cas par cas.

Si tu nous donnais un exemple plus concret (ce que représentent et ce que tu attend des différentes classes), nous pourrions surement t'orienter de manière beaucoup plus juste et précise :D

[EDIT]Pour la petite histoire, C++ accepte l'héritage public et les risques qu'il implique uniquement pour ne pas "brider l'imagination du développeur", au risque de le laisser se "tirer une balle dans le pied"... Ce n'est pas pour rien si d'autres langages ont, carrément, décidé de l'empêcher ;)
13/08/2010, 10h02
paparasta

J'ai envie de te donner un cas d'école qui se rapproche du miens

A = vehicule (couleur)
B = voiture a essence (couleur, reservoir d'essence)
C = voiture electrique (couleur, batterie electrique)
D = véhicule à moteur hybride (couleur, reservoir d'essence, batterie electrique)

comment penses tu que je pourrais faire autrement?
(par exemple en Java, comment ca se ferait)

merci bcp pour ton aide

Déjà, la motorisation n'est qu'un "détail d'implémentation" de la voiture, qui, elle, est un véhicule ;)

Une voiture hibride n'est donc pas une voiture à essence "couplée" à une voiture électrique, mais, bel et bien une "voiture" ayant une motorisation double :D

tu pourrais donc avoir une hiérarchie "moteur" qui serait proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class Moteur { /* ce qui est intéressant */ }; class MoteurEssence : public Moteur { /* Ce qui est propre au moteur à essence */ }; class MoteurElectrique : public Moteur { /* Ce qui est propre au moteur électrique */ }; /* pourquoi pas ??? */ class MoteurNucleaire : public Moteur { /* ce qui est propre au moteur nucléaire */ };
A l'extrême limite, tu pourrais prévoir pou chaque type de moteur une classe d'interface qui n'expose d'un point de vue du véhicule (est-ce seulement une voiture :question) que ce qui est propre au moteur en question
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class MotorisableEssence { public: MotorisableEssence(MoteurEssence const & m):m_(m){} virtual ~MotorisabelEssence() = 0; bool needFuel() const{return m_.reservoireVide();} private: MoteurEssence m_; }; class MotorisableElectrique { public: MotorisableElectrique(MoteurElectrique const & m):m_(m){} virtual ~MotorisableElectrique() = 0; bool needCharge() const{return m_.batterieVide();} }; /*...*/
Ensuite, tu aurais une hiérarchie de classes qui te permet de gérer les différents types de véhicules.
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 class Vehicule { /* ce qui est commun à tous les véhicules */ }; class Voiture : public Vehicule { /* ce qui est propre aux voiture, mais commun quelle que soit * la motorisation */ }; class VoitureEssence : public Voiture, public MotorisableEssence { }; class VoitureElectrique : public Voiture, public MotorisableElectrique { }; class VoitureHybride : public voiture, public MotorisableEssence, public MotorisableElectrique { };
De cette manière, chaque hiérarchie peut évoluer de manière tout à fait séparée et distincte, même si l'invention d'une nouvelle motorisation provoquera sans doute fatalement la création de... trois nouvelles classes ( le moteur, l'interface qui l'utilise et... la voiture qui hérite l'interface :D)

Cette approche serait sans doute utilisable dans la plupart des langages OO ;)
[EDIT]Tu pourrais éventuellement envisager de faire hériter VoitureHybride de VoitureEssence ou de voitureElectrique (selon les caractéristiques que tu veux mettre en avant) et de MotorisableElectrique ou de MotorisableEssence (en fonction de l'autre héritage)

Mais il est généralement préférable de garder les niveaux d'héritages des hiérarchies aussi "bas que possible" (préférer avoir des classes soeurs à des classes enfant de classes enfants ;))

13/08/2010, 10h58
paparasta

Merci bcp pour cet exemple détaillé.

C'est vrai qu'un cas générique avec des A, B ... est un mauvais point de vue puisque par définition, il n'est pas possible de découpler les différents aspects des classes.

Je vais voir comment repenser mon schéma donc, merci encore.
13/08/2010, 14h00
Flob90

Pour ta question sur l'initialisation de A, c'est justement une conséquence de l'héritage virtuel. Celuic-i indique que ce sera à la classe la plus dérivé d'initialiser A et pas forcément à la classe que tu es en train d'écrire, donc je ne vois pas de méthode simple (et qui reste dans l'idée d'une structure polymorphique) pour éviter de répéter cette initialisation.

@koala: Un langage OO qui interdit l'héritage publique ca existe ? Comment il fait le polymorphisme ? (langage ducked-type à part)
13/08/2010, 17h45
white_tentacle

Citation:

@koala: Un langage OO qui interdit l'héritage publique ca existe ? Comment il fait le polymorphisme ? (langage ducked-type à part)

Je crois que le clavier de koala a fourché et qu'il voulait dire multiple et pas public :).
13/08/2010, 20h15
NoIdea

Il me semble qu'il existe des cas où le losange de la mort se justifie :

Par exemple, si on souhaite créer un Qfilm (je ne sait pas si Qt en propose un ou pas) on pourrait vouloir le faire hérité de QSound et QWidget qui héritent de QObject donc, on retrouverait un losange.

Je ne pense donc pas, que le losange de la mort est toujours un problème de conception, mais qu'il est souvent mal utilisé.
13/08/2010, 21h02
koala01

Citation:

Envoyé par Flob90

@koala: Un langage OO qui interdit l'héritage publique ca existe ? Comment il fait le polymorphisme ? (langage ducked-type à part)

Citation:

Envoyé par white_tentacle

Je crois que le clavier de koala a fourché et qu'il voulait dire multiple et pas public :).

:king:

Bien vu... c'est effectivement mon clavier qui a fourché :aie:

Citation:

Envoyé par NoIdea

Il me semble qu'il existe des cas où le losange de la mort se justifie :

Par exemple, si on souhaite créer un Qfilm (je ne sait pas si Qt en propose un ou pas) on pourrait vouloir le faire hérité de QSound et QWidget qui héritent de QObject donc, on retrouverait un losange.

Je ne pense donc pas, que le losange de la mort est toujours un problème de conception, mais qu'il est souvent mal utilisé.

Le fait est que l'on peut déjà se demander si l'héritage de QObject se justifie.

Il y a eu récemment un long débat sur l'intérêt des super objet / god object, et, personnellement, je ne suis toujours par persuadé de son opportunité :aie:

Tu remarquera d'ailleurs que la plupart des langages qui interdisent l'héritage multiple utilisent, justement, un super objet, à moins qu'on ne le voie dans l'autre sens : parce qu'ils utilisent un super objet, les langages interdisent l'héritage multiple pour, justement, éviter d'en arriver au losange de la mort :D
13/08/2010, 21h14
dourouc05

Citation:

Envoyé par NoIdea

Par exemple, si on souhaite créer un Qfilm (je ne sait pas si Qt en propose un ou pas) on pourrait vouloir le faire hérité de QSound et QWidget qui héritent de QObject donc, on retrouverait un losange.

AMHA, c'ets un mauvais exemple. En effet, un QFilm représente un film : je le vois plutôt comme la bande que l'on transmet au cinéma. Ensuite, il te faut un widget pour afficher ce film, un QFilmWidget : le couple bâche de projection/projecteur. Aussi, un film n'est pas un son, un film comporte une bande son : ton QFilm aurait deux parties, une pour les données vidéo, une pour les données audio (QSound). Ce ne serait qu'une manière plaisante de rassembler les deux, de les démultiplexer ou quelque chose du genre. Donc, dans cette vision, ce serait un problème de conception.