Discussion :

[JolyLoic]

Bonjour à tous !

Je viens de mettre en ligne un article, intitulé : Héritage multiple en C++ : Pourquoi l'héritage d'interfaces est insuffisant

N'hésitez pas à faire donner votre avis, faire des remarques. L'article compare aussi des fonctionnalités de différents langages orientés objet, principalement C++, C# et Java. En tant que tel, j'espère qu'il pourra susciter des discussions intéressantes, sans sombrer dans le troll inter-langages.

Bonne lecture !

[jmv]

Super plaidoyer pour l'héritage multiple

Enfin quelqu'un qui défend cette notion qu'il est "politiquement correct" de décrier.

Merci

juste 2 remarques :

Code :

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

assert(montant > solde());

J'espère que tu ne développe pas pour une banque !

Et au chapitre 3-B, je me demande si le 1er diagramme de classe est correct (classe A définie 2 fois), et s'il l'est, il me semble identique au 2eme (même si on comprend bien grace à ces 2 diagrammes ce que tu veux montrer).

Du bon boulot en tous cas.

jmv

[screetch]

Salut,
c'est un très bon papier


mais pour la partie 2B, je ne suis pas sur que l'héritage (multiple ou pas) soit la bonne solution, on dirait plutôt que quelqu'un a abusé de l'héritage. Dans ce cas, il faudrait plutot faire de la composition que de l'héritage (c'est un problème que je retrouve dans toutes les bibliothèques IHM que je connais; faire un widget c'est environ 8 niveaux d'héritage)

[JolyLoic]

juste 2 remarques :

Code :

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

assert(montant > solde());

J'espère que tu ne développe pas pour une banque !

Rassure toi, tu peux dormir sur tes deux oreilles

Et au chapitre 3-B, je me demande si le 1er diagramme de classe est correct (classe A définie 2 fois), et s'il l'est, il me semble identique au 2eme (même si on comprend bien grace à ces 2 diagrammes ce que tu veux montrer).

En effet, je ne pense pas qu'UML permette d'exprimer cette notion, et mes diagrammes ne sont donc probablement pas des diagrammes UML standards. Encore un exemple qui démontre que malgré ses désirs d'universalité, UML a été pensé avec certains types de langages en tête, et ne permet pas vraiment de représenter toutes les notions de tous les langages.

[JolyLoic]

mais pour la partie 2B, je ne suis pas sur que l'héritage (multiple ou pas) soit la bonne solution, on dirait plutôt que quelqu'un a abusé de l'héritage. Dans ce cas, il faudrait plutot faire de la composition que de l'héritage (c'est un problème que je retrouve dans toutes les bibliothèques IHM que je connais; faire un widget c'est environ 8 niveaux d'héritage)

Je suis assez d'accord avec toi, le domaine de l'IHM abuse généralement des hiérarchies d'héritage profondes, et obligent souvent à dériver des classes fournies par la bibliothèque pour personnaliser le comportement (même si je trouve que la situation s'améliore, par exemple, en WPF, on peut faire moult personnalisations sans aucune dérivation, avec entre autre la notion de templates d'affichage qui permet d'indiquer comment un composant graphique logique va créer ses composants graphiques visuels).

Le fait est qu'il faut tout de même faire avec. Et si le cas des IHM est emblématique des cas où l'on doit dériver de classes d'une hiérarchie existante et non modifiable, il n'est pas le seul.

[white_tentacle]

Article super intéressant , à faire lire à tous les javateux et autres csharpeux qui ne comprennent pas pourquoi on se sent frustré quand on code dans leur langage chéri.

Seule petite remarque, je trouve dommage de présenter le NVI pour vérifier les contrats comme un avantage à l’héritage multiple de code. C’est plus un palliatif moins mauvais que ce qu’on a dans les autres langages. Théoriquement, les contrats font partie de l’interface de la fonction, pas de son code. Je ne l’aurais en tout cas pas mis en premier, je trouve les deux autres exemples beaucoup plus convaincants .

[vincepoencet]

Très intéressant bravo !
Surtout que je me suis dev C# et qu'en se moment je me met au c++, ça tombe à pic .

J'ai survolé pour l'instant, mais je peut dire que sans héritage multiple, on peut aussi ne pas dupliquer de code, en général grâce à la composition.
ça évite aussi d'avoir des classes "qui font tout", 1ère chose à laquelle je pense quand je vois écrit héritage multiple.

En tout cas merci, j'ai hâte de m'y plonger ce soir

[jblecanard]

Excellent, j'ai appris beaucoup de choses

[Luc Hermitte]

Hello.
Super initiative. Je vais y gagner en moins de radotage grâce à toi Merci !

Je ne suis pas super fan des exemples sur les widgets. Essentiellement parce que nous sommes dans un cas de base commune. De fait dans ces cas là j'ai un red flag qui se lève et je tends à me méfier pour utiliser le MI.
Avec deux sources différentes, je n'ai plus aucun scrupule. Mais il est vrai que l'on rejoint là les politiques (mais sans l'aspect template)(mince j'ai oublié le nom donné aux classes à destructeur protégé non-virtuel dans le C++CS de Sutter&Alexandrescu, ce n'était pas "politique" il me semble, mais autre chose)

En ordre d'importance, je place comme Loic le NVI parmi l'argument principal. Les politiques viennent ensuite.

Je serai revenu sur le LSP dans la partie sur les problèmes : Pour que le MI marche, il faut a minima comprendre et respecter le LSP sur chaque axe d'héritage. Quand on commence à tout mélanger, c'est là que l'on ne s'en sort plus. Et le gros problème du MI, c'est souvent que l'héritage simple n'était pas compris. Comment étendre sereinement à plus d'une classe sous de telles conditions ?

[j-jorge]

Bonjour,

C'est un article très intéressant qui réveille quelques interrogations que je me pose quant à la mise en œuvre de l'héritage multiple.

Dans l'exemple 3-A (où il manque la déclaration d'héritage au passage), on définit que B est un A et que C est un A. Mais D qui est un B et un C n'est pas "un" A, il multiplie les qualités de A. Cela me semble contre intuitif.

Ainsi, j'ai le sentiment que l'héritage en losange est le résultat naturellement attendu quand on hérite plusieurs fois d'une même classe. Or ce n'est pas le comportement par défaut.

De plus, comme la qualité de l'héritage de A est définit au niveau de B et C, j'ai l'impression qu'aucun type d'héritage n'est satisfaisant. Par exemple, à supposer que j'écrive une bibliothèque où A, B et C sont définies sans héritage virtuel et qu'un utilisateur de ma bibliothèque définisse un D héritant de B et C. Il se retrouve dans l'impossibilité de choisir un héritage en losange. Du coup, lors d'un appel à une fonction de la bibliothèque prenant un A, il devra choisir s'il s'agit du A de B ou du A de C.

Alors quel comportement adopter en pratique pour ne pas bloquer les futurs développeurs ni les évolutions du logiciel ? Faut-il tout mettre en héritage virtuel ?

[Flob90]

@j-jorge: Si il n'y a pas d'héritage virtuel, alors en effet un D n'est pas un A (tu peux tester, une instance de D ne peux pas être donné là où un A est attendu, LSP). Pourquoi la relation "est un" serait toujours transitive ?

[Klaim]

Ainsi, j'ai le sentiment que l'héritage en losange est le résultat naturellement attendu quand on hérite plusieurs fois d'une même classe. Or ce n'est pas le comportement par défaut.

Suivant les idiomes du C++, je ne trouve pas que ce soit un résultat naturellement attendu. Habituellement le C++ manipule tout par valeur, ce qui sous entends qu'un agregat de deux types, quels que soient leur relations, est équivalent (moyennant agencements mémoire) à deux objets de ces deux types "collés ensembles" du point de vue de la mémoire. Or ce principe ignore totalement le fait que les deux types pourraient avoir une base commune qui est donc répétée pour chaque type parcequ'ils ont chacun un état séparé.

Du coup, la solution de l'héritage virtuel m'apparait comme une exception parceque contrairement aux idiomes habituels du C++, cette feature permet de dire explicitement au language qu'on sait qu'il y a une relation entre les types et qu'on veut que leurs états soient partagés.

Je ne sais pas pour vous, mais il m'est arrivé rarement d'avoir recours à l'héritage virtuel, pour une hierarchie bien précise. Du coup j'ai plutot tendance à penser que c'est cela l'exception, et que l'heritage multilpe tout court est juste plus facile à penser par défaut.

En fait, je me dit qu'il n'y a que dans des cas de hierarchies prédéfinies et fixes (c'est à dire qui n'est pas fait pour être étendu) que c'est vraiment utile. Mais j'imagine que je manque de pratique dans le sujet.

[white_tentacle]

Je ne sais pas pour vous, mais il m'est arrivé rarement d'avoir recours à l'héritage virtuel, pour une hierarchie bien précise. Du coup j'ai plutot tendance à penser que c'est cela l'exception, et que l'heritage multilpe tout court est juste plus facile à penser par défaut.

En général, si tu as de l’héritage en losange, c’est parce que tu as un super objet. Comme en C++ on essaie d’éviter de recourir à des super objets, le cas est forcément peu fréquent.

[Klaim]

En général, si tu as de l’héritage en losange, c’est parce que tu as un super objet. Comme en C++ on essaie d’éviter de recourir à des super objets, le cas est forcément peu fréquent.

C'est pas bête. Je n'utilises que rarement les super objets...

L'autre cas où j'ai du jongler avec l'héritage virtuel c'était pour faire une sorte de mixin sur deux axes pour définir des "interpolations"... mais c'était un peu overkill j'imagine : http://www.ogre3d.org/forums/viewtop...44879&p=308589

[David Fleury]

Merci pour cet article.
C'est très clair et enrichissant.

[Drannor]

Je trouve la partie 1 & 2 bien. Par contre la 3ème partie c'est du survol et je trouve ça dommage.

On explique pas réellement comment fonctionne l'héritage virtuel et quel est le coût de son utilisation (j'aimerais bien le savoir).

Je trouve la partie sur le cast trop rapide. Il manque une schématisation d'une classe mono héritage versus multi héritage pour bien comprendre l'histoire de décalage du pointeur lors du cast.

Après un rappel sur la RTTI n'aurait pas été de refus quand on en arrive au dynamic_cast.

Il y a une erreur dans l'exemple : 3-A.

Mais merci pour cette article.

[screetch]

Je trouve la partie sur le cast trop rapide. Il manque une schématisation d'une classe mono héritage versus multi héritage pour bien comprendre l'histoire de décalage du pointeur lors du cast.

Après un rappel sur la RTTI n'aurait pas été de refus quand on en arrive au dynamic_cast.

surtout que le dynamic_cast ne compile pas sur cet exemple, puisque pour utiliser le dynamic_cast il faut une table de méthode virtuelle (c'est la qu'on stocke l'info RTTI)

[3DArchi]

On explique pas réellement comment fonctionne l'héritage virtuel et quel est le coût de son utilisation (j'aimerais bien le savoir).

Peut être parce que c'est un détail d'implémentation et que ça varie d'un compilateur (voire d'une version/option de compil/code particulier) à l'autre?
En général, entre un héritage simple et un héritage multiple, on ne fait que cumuler les vtable, et, en bonus, en cas d'héritage virtuel, on rajoute un offset (soit dans la vtable avec gcc, soit à part dans VC si ma mémoire est bonne). Dynamiquement, le cross cast peut aussi être impacté (toujours avec de l'héritage virtuel). Mais, voilà. A quoi cela peut servir d'avoir ce coût ?

[Drannor]

A quoi cela peut servir d'avoir ce coût ?

Connaître comment une fonctionnalité est implémentée permet de comprendre l'impact sur les performances (exécution & mémoire) que cela peu avoir surtout quand on fait du temps réel embarqué comme c'est mon cas.

[3DArchi]

Connaître comment une fonctionnalité est implémentée permet de comprendre l'impact sur les performances (exécution & mémoire) que cela peu avoir surtout quand on fait du temps réel embarqué comme c'est mon cas.

Sans contexte, connaitre l'implémentation est intéressant. Cependant, ces aspects de coûts restent pour moi un faut débat (ou une illusion) : quel est le coût amené par le langage versus quel est le coût amené par la complexité du projet et son design ? AMHA, le principal contributeur en empreinte mémoire/temps d'exécution se situe entre le clavier et la chaise, pas sur les features du langage utilisé.