Pourquoi C # ne prend pas en charge l'héritage multiple?


10

Même s'il peut s'agir de mauvaises pratiques, je dirais qu'il est temps qu'elle remplisse son objectif.


1
J'adore la façon dont tout le monde fait toutes ces excuses pour l'absence d'une capacité totalement utile dans tout ce que Microsoft produit (les MVP sont particulièrement aptes à cela). Je suppose que la plupart des gens qui ne comprennent pas les avantages de l'héritage multiple sont ceux qui ne comprennent pas (et n'utilisent pas) l'héritage en premier lieu, car ils préfèrent la copie et- collez-le-code-20 fois que je vois dans presque tous les projets partout. Nul doute que si et quand Microsoft décide d'implémenter MI, tout le monde deviendra soudainement un passionné averti, n'attendez pas un "évangéliste", prétendant

1
@DaveZiffer probablement, mais il semble difficile de bien faire les choses. Connaissez-vous un langage ou une implémentation où cela fonctionne vraiment bien?

4
@Dave Ou vous surestimez simplement son utilité. L'héritage en général est largement surévalué et les cas manquants peuvent être facilement modélisés à l'aide des interfaces et de la composition. L'héritage multiple est vraiment inutile en C #. Le seul avantage est qu'il évite la nécessité de déléguer manuellement les méthodes d'interface à l'implémentation dans les membres composites. Cela aurait pu être mieux résolu (par exemple en introduisant des mixins) mais ce n'est pas une bonne raison pour introduire l'héritage multiple.
Konrad Rudolph

Je code OO en java depuis de nombreuses années maintenant en faisant un usage raisonnable de l'héritage (beaucoup parfois, moins quand j'ai mieux appris) et j'ai trouvé exactement 1 fois où il était vraiment difficile de contourner l'héritage multiple et peut-être 10 fois où j'aurais pu l'utiliser pour simplifier ma conception actuelle - et exactement zéro fois où je ne pouvais pas la repenser pour ne pas avoir besoin d'héritage multiple et avoir une conception globale meilleure qu'elle ne l'aurait été avec.
Bill K

Réponses:


14

/programming/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c couvre bien cette question.

Mon opinion est la suivante: les concepteurs voulaient probablement créer un langage qui promeuve de bons principes de conception. Ok, il y a donc des moments où l'héritage multiple est parfait. Ce sont l'exception, plutôt que la règle, cependant, et peuvent être abusées très facilement. Ainsi, les concepteurs ont décidé de rendre cela impossible.

Pour les cas où ce serait bien, vous devez utiliser des interfaces. Ces travaux, quoique maladroitement; mais vous n'en aurez pas besoin pour autant.


8

Juste pour illustrer pourquoi, l'héritage multiple est pris en charge par C ++, mais est fortement déconseillé car vous pouvez accomplir la plupart des choses avec la composition que vous feriez avec MI, mais de manière beaucoup plus propre. Contrairement à C ++, C # n'est pas un langage OOP de type "hybride", c'est-à-dire qu'il n'a pas évolué à partir d'un langage précédent.

Si vous avez vraiment besoin d'un héritage multiple, vous pouvez implémenter plusieurs interfaces.


6

Walter Bright est à la fois le créateur de D, qui n'inclut pas MI, et la seule personne à avoir écrit un compilateur C ++ entier par lui-même. Selon lui, la raison pour laquelle D manque de MI est qu'il est trop difficile de créer un système de MI à la fois efficace, simple et utile. Je soupçonne que Java et C # utilisent un raisonnement similaire. Les langages comme Perl et Python n'ont pas l'efficacité comme objectif principal, ils ont donc un système simple et utile, mais difficile à mettre en œuvre efficacement. Le C ++ ne semble pas avoir pour objectif la simplicité, il a donc créé un système extrêmement compliqué que presque personne ne comprend.

Je pense que Walter a raison. S'il existe une langue qui dispose d'un système MI qui satisfait raisonnablement bien à ces trois critères, veuillez laisser un commentaire.


2
Que pensez-vous d'Eiffel, du Common Lisp et de Dylan? Je sais que tous les trois sont à la fois simples et utiles. Et je sais que Common Lisp et Dylan peuvent rivaliser et même battre C ++ (et souvent même C) en termes de performances, ce qui semble satisfaire l'efficacité. Je ne sais que la Tour Eiffel compilateur est horriblement lent , mais je sais presque rien sur les performances du code compilé produit.
Jörg W Mittag


-1

Parce que les concepteurs de langage voulaient apparemment produire un meilleur C ++, pas un meilleur langage en général. (Leur succès peut être débattu.)

L'héritage multiple de style C ++ a quelques problèmes, donc les personnes dérivant du C ++ l'ont généralement omis (Java, C #, D). D'autres langues, Eiffel et Common Lisp pour n'en nommer que deux, le font différemment et ne semblent pas avoir les mêmes problèmes.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.