Pourquoi l'Héritage Multiple n'est autorisé en Java ou en C#?

Question

Je sais que l'héritage multiple n'est pas autorisé en Java et en C#. De nombreux livres juste dire, l'héritage multiple n'est pas autorisé. Mais il peut être mis en œuvre par l'utilisation d'interfaces. Rien n'est discuté au sujet de pourquoi il n'est pas permis. Quelqu'un peut-il me dire précisément pourquoi il n'est pas permis?

Answer 1

La réponse courte est: parce que la langue de créateurs ont décidé de ne pas.

Fondamentalement, il semble que les deux .NET et Java concepteurs ne permet pas l'héritage multiple, car ils estiment que l'ajout de MI ajouté trop de complexité pour les langues tout en offrant trop peu d'avantages.

Pour plus de plaisir et en profondeur de lire, il y a quelques articles disponibles sur le web, avec des interviews de certains de la langue des designers. Par exemple, pour les .NET, Chris Brumme (qui a travaillé chez MS sur la CLR) a expliqué les raisons pour lesquelles ils ont décidé de ne pas:

1. Différentes langues effectivement avoir des attentes différentes pour comment MI des œuvres. Par exemple, comment les conflits sont résolu et si dupliquer les bases sont fusionnées ou redondantes. Avant que nous puissions mettre en œuvre des MI dans le CLR, nous avons à faire une étude de toutes les langues, la figure les concepts communs, et de décider comment les exprimer dans un langue de manière neutre. Nous aussi décider si MI appartient à le CLS et ce que cela signifie pour les langues qui ne veulent pas ce concept (sans doute VB.NET, par exemple). De bien sûr, c'est l'entreprise, nous sommes en comme common language runtime, mais nous n'ai pas eu à le faire pour MI encore.

2. Le nombre de lieux où MI est vraiment approprié est en fait assez petite. Dans de nombreux cas, plusieurs l'héritage de l'interface peuvent obtenir le travail fait à la place. Dans d'autres cas, vous pouvez être en mesure d'utiliser l'encapsulation et délégation. Si nous devions ajouter une légèrement différent de construire, comme mixin, serait-ce en fait être plus puissant?

3. Plusieurs mise en œuvre de l'héritage injecte beaucoup de complexité dans le la mise en œuvre. Cette complexité les impacts de la coulée, la mise en page, d'expédition,de accès sur le terrain, la sérialisation, l'identité comparaisons de vérifiabilité, la réflexion, les génériques, et probablement beaucoup d'autres endroits.

Vous pouvez lire l'intégralité de l'article ici.

Pour Java, vous pouvez lire cet article:

Les raisons de l'omission d'un multiple l'héritage du langage Java pour la plupart de la tige à partir de la "de simples, objet et bien" le but. En tant que un langage simple, Java créateurs voulait une langue que la plupart des développeurs pourrait saisir l'étendue de la formation. À cette fin, ils ont travaillé à l' faire de la langue semblable à celle du C++ possible (familier) sans porter cours de C++de la complexité inutile (simple).

Dans le designers' opinion, de multiples l'héritage provoque plus de problèmes et la confusion qu'elle n'en résout. Donc ils ont coupé l'héritage multiple de la langue (juste comme ils ont coupé l'opérateur la surcharge). Les concepteurs vaste C++ expérience leur a appris que l'héritage multiple n'était tout simplement pas la peine les maux de tête.

Answer 2

L'héritage Multiple de la mise en œuvre est ce qui n'est pas autorisé.

Le problème est que le compilateur/runtime ne peut pas comprendre ce qu'il faut faire si vous avez un cow-boy et un Artiste de classe, à la fois avec les implémentations de la méthode draw (), et puis vous essayez de créer un nouveau CowboyArtist type. Ce qui se produit lorsque vous appelez la méthode draw ()? Quelqu'un est couché mort dans la rue, ou vous avez une belle aquarelle?

Je crois que ça s'appelle le diamant double héritage problème.

Answer 3

Raison: Java est très populaire et facile à code, en raison de sa simplicité.

Donc, ce que jamais développeurs java se sentir difficile et compliquée à comprendre pour les programmeurs, ils ont essayé de l'éviter. Un tel type de propriété qui est l'héritage multiple.

1. Ils ont évité les pointeurs
2. Ils ont évité l'héritage multiple.

Problème de l'héritage multiple: Diamant problème.

Exemple:

1. Supposons que la classe A est de disposer d'une méthode de fun(). de classe B et de classe C dérive de la classe A.
2. Et les deux classes B et C, remplace la méthode de fun().
3. Supposons maintenant que la classe D hérite à la fois de la classe B, et C. (juste à l'Assomption)
4. Créer un objet de classe D.
5. D D = new D();
6. et essayez d'accéder à d.fun(); => il a fait appel de la classe B est amusant() ou la classe C est amusant()?

C'est l'ambiguïté existant dans diamant problème.

Il n'est pas impossible à résoudre ce problème, mais il ne crée plus de confusion et de complexité pour le programmeur lors de la lecture. Il cause plus de problème qu'il tente de résoudre.

Remarque: Mais de toute façon, vous pouvez toujours mettre en œuvre l'héritage multiple indirectement par l'utilisation d'interfaces.

Answer 4

Parce que Java est très différente de la conception de la philosophie à partir de C++. (Je ne vais pas discuter de C# ici).

Dans la conception de C++, Stroustrup voulu inclure des fonctionnalités utiles, indépendamment de la façon dont elles pourraient être utilisées à mauvais escient. Il est possible de visser les grands moments de l'héritage multiple, la surcharge des opérateurs, des modèles, et d'autres caractéristiques différentes, mais il est aussi possible de faire de très bonnes choses avec eux.

La Java philosophie de conception est de l'accent sur la sécurité dans les constructions de langage. Le résultat est qu'il y a des choses qui sont beaucoup plus compliqué à faire, mais vous pouvez être beaucoup plus confiant que le code que vous êtes en train de regarder les moyens ce que vous pensez que cela fonctionne.

De plus, Java a été en grande partie une réaction à partir de C++ et Smalltalk, le plus connu des langages à objets. Il ya beaucoup d'autres langages à objets (Common Lisp est effectivement la première à être standardisés), avec différents OO des systèmes qui gèrent MI mieux.

Ne pas oublier qu'il est tout à fait possible de faire MI en Java, en utilisant des interfaces, de la composition, et de la délégation. C'est plus explicite qu'en C++, et est donc plus encombrant à utiliser, mais vous obtiendrez quelque chose de que vous êtes plus susceptibles de comprendre au premier coup d'œil.

Il n'y a pas de bonne réponse ici. Il y a des réponses différentes, et qui est la meilleure pour une situation donnée dépend des applications et des préférences individuelles.

Answer 5

Le principal (mais pas la seule) raison pour laquelle les gens à se détourner de la MI est la soi-disant "diamant problème", conduisant à une ambiguïté dans votre imlpementation. Cet article de wikipédia en discute et explique mieux que je le pouvais. MI peut aussi conduire à un code plus complexe, et beaucoup de OO concepteurs de prétendre que vous n'avez pas besoin de MI, et si vous ne l'utilisez votre modèle est probablement faux. Je ne suis pas sûr que je suis d'accord avec ce dernier point, mais garder les choses simples est toujours un bon plan.