dangers de l'héritage multiple

salut,

je me rappel vraiment plus , mais on m'avait mis en garde contre certains dangers de l'héritage multiple en c++.

Qui peut m 'en dire plus merci bcp d'avance.

Pour ma part, il me semble qu'a part des fonctions ou membres portant le meme nom, on ne devrait pas rencontrer de difficultées...

les pros, vous en dites quoi ?

Le vrais danger c'est l'héritage en diamant

class A
{
int val;
}
class B : public A
{
initialise, dans le constructeur val à 5
}
class C : public A
{
initialise, dans le constructeur val à 8
}

class D : public B, public C
{
QUE VAUX VAL???
}

Citation:

---

Envoyé par Mizar75

QUE VAUX VAL???

---

ben bonne question alors.

Idem pour une methode virtuel défini dans A et implementé dans B et C.

Si on l'appel depuis D quel code va s'executer?

Ceci est solutionné par l'héritage virtuel ;)

Citation:

---

Envoyé par Alp

Ceci est solutionné par l'héritage virtuel ;)

---

C'est quoi?

ceci n'est pa solutionné par la virtualité,ca ne va meme pas passer à la compilation,sinn pr remedier au probleme,il suffit d'utiliser l'operateur

Salut,

Selon moi, la possibilité de faire de l'héritage multiple est une bonne chose.

Je suis un peu triste que des langages comme Java ou C# ne permettent pas de faire de l'héritage multiple, car au final les problèmes qui y sont liés ne sont rien de plus que des erreurs de modélisation. A mon avis, le fait que des langages comme Java ou C# ont fait l'impasse dessus, réside dans la complexité de compilation liée à cette fonctionnalité qui aurait impliqué une certaine lenteur -> pour un langage semi-compilé, c'est gênant.

L'héritage multiple est cependant une fonctionnalité importante et utile lorsqu'on fait une application complexe. En C++ par exemple, quand on prend soin de faire un bon design, l'héritage multiple n'est jamais problématique.

Je me suis fait à la programmation par interfaces, mais il y a des situations où on sent bien que l'héritage multiple aurait été la solution la plus élégante et intuitive.. Et il est dommage de devoir utiliser des ruses pour imiter quelque chose d'aussi simple dans le concept :(

A+

Le mot "dangers" est un peu fort je trouve, car il me semble que tout les compilateurs arrivent à déceler ces problèmes lors de la compilation...
Cependant, il est vrais que SUN ou même les bouquins / doc JAVA, il n'hésite pas à utiliser ce mot pour essayer de vendre leur fausse solution d'interface :’(

Citation:

---

Envoyé par bouzaidi

ceci n'est pa solutionné par la virtualité,ca ne va meme pas passer à la compilation,sinn pr remedier au probleme,il suffit d'utiliser l'operateur

---

Non je pense pas non plus. En fait tous ce joue au niveau du compilateur qui à ses propres régles. Certain accepte de compiller d'autre non.
L'idéal est de ne pas faire.

Sinon moi aussi je suis pour l'héritage multiple, bien pratique pour un bon découpage en classes.

Citation:

---

Envoyé par bouzaidi

ceci n'est pa solutionné par la virtualité,ca ne va meme pas passer à la compilation,sinn pr remedier au probleme,il suffit d'utiliser l'operateur

---

L'organigramme en diamant ne fonctionnera (ne compilera, même, sur un compilo digne de ce nom) que si l'on utilise l'héritage virtuel ( class B : virtual public A, ... ).

Salut à tous,

Juste pour info, il me semble que l'on utilise "héritage répété" pour un héritage en diamant...
Les dangers restent la mauvaise conception, comme toujours ! ;)
Pour les conflits de noms, je ne sais pas comment ça se gère en C++ ( à part les namespace introduit préalablement)

A+

Poukill a raison : le danger est plus lié à un problème de conception qu'au mécanisme de l'héritage multiple.

Bien souvent quand on se retrouve à vouloir faire de nombreux héritages multiples c'est qu'on à mal posé le problème. On s'appuie trop sur l'héritage pour éviter de redéfinir des fonctions et pas assez sur la composition.

Sur le même sujet :

Par exemple si on fait une classe abstraite Personne. Et deux classes filles qui en héritent : Etudiant et Chercheur.

Que faire si on souhaite créer un étudiant-chercheur ? :roll:
Probablement pas un diamant...

PS : je ne sais plus ou j'ai aperçu cet exemple, désolé pour la mauvaise citation au cas où ;)

C'est très pertinent.

La solution technique à l'héritage en diamant est l'héritage virtuel.
Ce n'est pas pour ça que c'est la meilleure solution.

L'héritage lui-même, simple, est trop souvent utilisé. On peut souvent remplacer l'héritage par la composition en obtenant un petit gain de performance, mais un énorme gain en flexibilité, souplesse du code.
L'héritage public est la relation la plus forte qui soit. La composition, elle, est une relation assez faible.

koala01 (désolé si je me trompe) en a parlé récemment dans un topic.

Citation:

---

Envoyé par KiLVaiDeN

Je me suis fait à la programmation par interfaces

---

Et bien pas moi... Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

interface I { void f(); void g(); };   class A : I, autreClassA { };   class B : I, autreClassB { };

---

Avec autreClassA et autreClassB des classes que je ne peux pas modifier (bibliothèque externe).

Je sais que f() peut s'implémenter en fonction de g(), toujours. Et bien, pas moyen d'écrire ça avec des interfaces. Le mieux que j'ai trouvé (et qui n'est pas top), c'est d'ajouter une autre classe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class IImplementation { static void f(I objet); };   void A::f() { IImplementation::f(this); }   void B::f() { IImplementation::f(this); }

---

Salut,

De manière générale, il est déjà utile de rappeler qu'il s'agit d'utiliser l'héritage avec pragmatisme.

Est il utile de rappeler l'un des principes de base énoncé dans la plupart des bouquins sérieux parlant de l'héritage:

Citation:

---

préférez la composition à l'héritage

---

Est il aussi utile de rappeler que, bien souvent, les problèmes que l'on peut avoir à gérer s'adaptent très bien à l'un des 23 design patterns identifiés par le Gang Of Four, ou à un "mix" de plusieurs d'entre eux :question:

Encore faut il être en mesure de reconnaître que l'on est dans une situation dans laquelle tel ou tel design patterns est utilisable... mais c'est un autre débat.

Ceci dit, je ne peux m'empêcher de penser que si "danger" il y a dans un héritage multiple, c'est surtout du fait que les phénomènes qu'il implique par "effet de bord" sont généralement mal compris, et résident dans la plupart des cas en d'éventuels conflits de nom de variable ou de fonction.

Le cas "peau de banane" étant bien sur l'héritage en losange ou en diamant :P

Le plus souvent, celui qui parlera de danger sera surtout celui qui n'a jamais pris la peine de réfléchir sereinement et complètement aux différentes implications :P

Mais, encore une fois, aucun des écueils qui pourraient apparaître du fait d'un héritage multiple (qu'il soit en losange ou non) n'est réellement insurmontable, pour autant que l'on soit conscient de son apparition...

Pour conclure, j'aurais envie de rappeler que, tant dans la vie de tous les jours qu'en programmation, rien n'est jamais sans danger si c'est fait de manière inconsidérée... Par contre, rien n'est dangereux si c'est fait à bon escient et en pleine connaissance des tenants et aboutissants :D