Discussion :

[JolyLoic]

L'héritage multiple est, en générale, à éviter.

Bof, je ne vois vraiment pas pourquoi...

[icer]

Bof, je ne vois vraiment pas pourquoi...

Tout simplement parceque ça n'est pas une bonne conception : surtout lorsqu'il y a des noms de membres communs dans les supers classes. Comment savoir quels membres vient de quelles classes.

Un exemple trés simple :

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
class A{
  int i;
};
 
class B{
  int i;
};
 
class C : A, B{
  int j;
};
 
C unC;
 
unC.i = 5; // Est-ce le i hérité de A ou celui hérité de B ?

C'est la même chose pour les méthodes.

Je le répéte : une conception avec de l'héritage multiple n'est pas une conception saine.

Il y a un cas où l'héritage multiple peut-être judicieux : lorsqu'on effectue une conception avec des interfaces, comme en java... dans les autres cas c'est fortement déconseillé. (sauf si on veut s'arracher les cheveux )

[coyotte507]

Bonsoir,

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
class A{
  int i;
};
 
class B{
  int i;
};
 
class C : A, B{
  int j;
};
 
C unC;
 
unC.i = 5; // Est-ce le i hérité de A ou celui hérité de B ?

Justement le compilateur n'autorise pas ça.
On peut y parvenir si le membre est dans une classe de base commune.

Il y a un cas où l'héritage multiple peut-être judicieux : lorsqu'on effectue une conception avec des interfaces, comme en java... dans les autres cas c'est fortement déconseillé. (sauf si on veut s'arracher les cheveux )

J'utilise l'héritage multiple pour une interface GUI (avec SDL), et c'est tellement utile dans ce domaine que j'ai du mal à croire qu'il n'est pas utile autre part.

[icer]

J'utilise l'héritage multiple pour une interface GUI (avec SDL), et c'est tellement utile dans ce domaine que j'ai du mal à croire qu'il n'est pas utile autre part.

Si ta bibliothéque de GUI est bien conçue, je peux te croire que c'est bien pratique. Le problème avec le c++ c'est qu'il ne différencit pas syntaxiquement un héritage d'une implémentation d'interface (ce que java fait). En c++ c'est au programmeur de faire la différence, donc à prendre plus de précaution avec l'héritage multiple, voir même l'éviter...

[JolyLoic]

J'ai eu à travailler pas mal ces derniers temps avec un langage qui permet l'héritage multiple d'interface, mais pas l'héritage multiple en général (C# en l'occurrence), et je peux te dire que le manque d'héritage multiple m'a conduit à écrire du code bien plus sale (avec duplication et tout) que si j'en avais eu.

Désolé de ne pouvoir décrire plus le problème ici (après tout, je ne suis pas proprio du code en question, et puis ça prendrait du temps à décrire). En particulier, j'aurais pu dans ce cas obtenir un résultat satisfaisant sans héritage multiple, mais il m'aurait fallu pour ça réorganiser les responsabilités autrement dans la hiérarchie de classes, et ça je ne pouvais pas le faire, car il s'agit de classes issues d'une bibliothèques externe. Avec l'héritage multiple, le problème était résolu en 2 lignes.

Je ne dis pas que l'héritage multiple (dans sa version complète) s'utilise tous les jours, dans toutes les hiérarchies de classes, mais je dis qu'il y a des cas où il est utile, et que dans ces cas, les alternatives sont beaucoup moins satisfaisantes.

Et je n'ai pas encore vu d'arguments qui expliqueraient en quoi l'héritage multiple serait problématique (à par que c'est plus difficile à implémenter, ce qu'en tant qu'utilisateur du langage, je n'ai rien à faire).

[icer]

... mais il m'aurait fallu pour ça réorganiser les responsabilités autrement dans la hiérarchie de classes...

L'héritage multiple t'a permis de "rattraper" une mauvaise conception de la bibliothèque... c'est plus pour une raison pratique que pour une raison de conception.

Et je n'ai pas encore vu d'arguments qui expliqueraient en quoi l'héritage multiple serait problématique (à par que c'est plus difficile à implémenter, ce qu'en tant qu'utilisateur du langage, je n'ai rien à faire).

Lors de la conception : on peut identifier exactement 4 types de relation entre classes :

- IS A : est un
- HAS A : a un , est composé d'un
- USES A : utilise un, communique avec un ...
- BEHAVES AS A : se comporte en tant que

L'héritage est implémenté uniquement pour "IS A" et "BEHAVES AS A".
Et dans le cas de "BEHAVES AS A", il s'agit d'interface, qui en c++ est implémenté grâce à l'héritage multiple.

[icer]

Personnellement, je ne vois pas pourquoi il s'agirait d'une mauvaise conception...

Après tout, la méthode UML autorise tout à fait d'y faire appel, et si on peut déconseiller dans certains d'y faire appel, c'est généralement pour la cause:

il est peut être utile de décider d'utiliser toutes les possibilités offertes par les méthodes de conception et par le langage

UML n'est pas une méthode mais un language. Dire qu'on peut le faire car UML le permet c'est dire : on peut tout faire car on peut le dire.

[koala01]

UML n'est pas une méthode mais un language. Dire qu'on peut le faire car UML le permet c'est dire : on peut tout faire car on peut le dire.

Mais, à partir du moment où:

1. le langage de programmation permet quelque chose
2. le langage de conception permet cette même chose

je ne vois de toutes manières aucune raison pour décider de se passer de cette possibilité sous prétexte qu'il "faut faire attention quand on l'utilise"...

Pour moi, aucune possibilité n'est mauvaise, même si on trouve pour certaines d'autres possibilités plus efficaces...

L'héritage multiple fait partie de ces possibilités pour lesquelles il est nécessaire de réfléchir à la différence entre la plus value qu'il fournit et les risques/problèmes qu'elles impliquent.

Si le bilan est globalement positif, que les circonstances sont clairement maîtrisées et correctement étudiées, pourquoi se refuser le recours à cette technique