Pourquoi n'y a-t-il pas d'héritage multiple en Java, mais l'implémentation de plusieurs interfaces est autorisée?


153

Java n'autorise pas l'héritage multiple, mais il permet d'implémenter plusieurs interfaces. Pourquoi?


1
J'ai modifié le titre de la question pour le rendre plus descriptif.
Bozho

4
Fait intéressant, dans le JDK 8, il y aura des méthodes d'extension qui permettront la définition de l'implémentation des méthodes d'interface. Les règles sont définies pour régir l'héritage multiple du comportement, mais pas de l'état (ce que je comprends est plus problématique .
Edwin Dalorzo

1
Avant que vous ne perdiez votre temps sur des réponses qui ne vous disent que "Comment java parvient à l'héritage multiple" ... Je vous suggère d'aller à @Prabal Srivastava réponse qui vous donne logiquement ce qui doit se passer en interne, pour ne pas autoriser les classes de ce droit. . et n'autorisent les interfaces qu'à autoriser l'héritage multiple.
Yo Apps

Réponses:


228

Parce que les interfaces spécifient uniquement ce que fait la classe, pas comment elle le fait.

Le problème avec l'héritage multiple est que deux classes peuvent définir différentes manières de faire la même chose, et la sous-classe ne peut pas choisir laquelle choisir.


8
J'avais l'habitude de faire du C ++ et j'ai rencontré le même problème à plusieurs reprises. J'ai récemment lu que Scala avait des "traits" qui me semblent être quelque chose entre la manière "C ++" et la manière "Java" de faire les choses.
Niels Basjes

2
De cette façon, vous évitez le "problème du diamant": en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem
Nick L.

6
Depuis Java 8, vous pouvez définir deux méthodes par défaut identiques, une dans chaque interface. Si vous implémentez les deux interfaces dans votre classe, vous devez remplacer cette méthode dans la classe elle-même, voir: docs.oracle.com/javase/tutorial/java/IandI/…
bobbel

6
Cette réponse n'est pas exacte. Le problème n'est pas de spécifier le comment et Java 8 est là pour le prouver. Dans Java 8, deux super interfaces peuvent déclarer la même méthode avec des implémentations différentes, mais ce n'est pas un problème car les méthodes d'interface sont virtuelles , vous pouvez donc simplement les écraser et le problème est résolu. Le vrai problème est l' ambiguïté des attributs , car vous ne pouvez pas résoudre cette ambiguïté en écrasant l'attribut (les attributs ne sont pas virtuels).
Alex Oliveira

1
Qu'entendez-vous par «attributs»?
Bozho

96

Un de mes instructeurs de collège m'a expliqué cela de cette façon:

Supposons que j'ai une classe, qui est un grille-pain, et une autre classe, qui est NuclearBomb. Ils peuvent tous les deux avoir un paramètre «obscurité». Ils ont tous deux une méthode on (). (L'un a un off (), l'autre pas.) Si je veux créer une classe qui est une sous-classe de ces deux ... comme vous pouvez le voir, c'est un problème qui pourrait vraiment exploser dans mon visage ici .

Donc, l'un des principaux problèmes est que si vous avez deux classes parentes, elles peuvent avoir des implémentations différentes de la même fonctionnalité - ou éventuellement deux fonctionnalités différentes avec le même nom, comme dans l'exemple de mon instructeur. Ensuite, vous devez décider lequel va utiliser votre sous-classe. Il existe des moyens de gérer cela, certainement - C ++ le fait - mais les concepteurs de Java ont estimé que cela compliquerait les choses.

Avec une interface, cependant, vous décrivez quelque chose que la classe est capable de faire, plutôt que d'emprunter la méthode d'une autre classe pour faire quelque chose. Plusieurs interfaces sont beaucoup moins susceptibles de provoquer des conflits délicats qui doivent être résolus que plusieurs classes parentes.


5
Merci, NomeN. La source de la citation était un doctorant du nom de Brendan Burns, qui à l'époque était également le mainteneur du référentiel open source Quake 2. Allez comprendre.
Syntaxique

4
Le problème avec cette analogie est que si vous créez une sous-classe d'une bombe nucléaire et d'un grille-pain, le «grille-pain nucléaire» exploserait raisonnablement lorsqu'il est utilisé.
101100

20
Si quelqu'un décide de mélanger une bombe nucléaire et un grille-pain, il mérite que la bombe lui explose au visage. La citation est un raisonnement fallacieux
masoud

1
Le même langage de programmation autorise l'héritage "d'interface" multiple, donc cette "justification" ne s'applique pas.
curiousguy

24

Parce que l'héritage est surutilisé même si vous ne pouvez pas dire "hé, cette méthode semble utile, je vais aussi étendre cette classe".

public class MyGodClass extends AppDomainObject, HttpServlet, MouseAdapter, 
             AbstractTableModel, AbstractListModel, AbstractList, AbstractMap, ...

Pouvez-vous expliquer pourquoi vous dites que l'héritage est surutilisé? Créer une classe de Dieu est exactement ce que je veux faire! Je trouve tellement de gens qui travaillent autour de l'héritage unique en créant des classes "Tools" qui ont des méthodes statiques.
Duncan Calvert

9
@DuncanCalvert: Non, vous ne voulez pas faire ça, pas si ce code aura un jour besoin de maintenance. Beaucoup de méthodes statiques passent à côté du point d'OO, mais l'héritage multiple excessif est bien pire parce que vous perdez complètement la trace du code utilisé où, ainsi que de ce qu'est conceptuellement une classe. Les deux essaient de résoudre le problème de "comment puis-je utiliser ce code là où j'en ai besoin", mais c'est un simple problème à court terme. Le problème à long terme beaucoup plus difficile résolu par une conception OO appropriée est «comment changer ce code sans interrompre le programme à 20 endroits différents de manière imprévisible?
Michael Borgwardt

2
@DuncanCalvert: et vous résolvez cela en ayant des classes avec une cohésion élevée et un faible couplage, ce qui signifie qu'elles contiennent des éléments de données et de code qui interagissent intensivement les uns avec les autres, mais interagissent avec le reste du programme uniquement via une petite API publique simple. Ensuite, vous pouvez y penser en termes de cette API au lieu des détails internes, ce qui est important car les gens ne peuvent garder à l'esprit qu'un nombre limité de détails en même temps.
Michael Borgwardt

18

La réponse à cette question réside dans le fonctionnement interne du compilateur java (chaînage de constructeur). Si nous voyons le fonctionnement interne du compilateur java:

public class Bank {
  public void printBankBalance(){
    System.out.println("10k");
  }
}
class SBI extends Bank{
 public void printBankBalance(){
    System.out.println("20k");
  }
}

Après avoir compilé, cela ressemble à:

public class Bank {
  public Bank(){
   super();
  }
  public void printBankBalance(){
    System.out.println("10k");
  }
}
class SBI extends Bank {
 SBI(){
   super();
 }
 public void printBankBalance(){
    System.out.println("20k");
  }
}

lorsque nous étendons la classe et en créons un objet, une chaîne de constructeur fonctionnera jusqu'à Object classe.

Le code ci-dessus fonctionnera bien. mais si nous avons une autre classe appelée Carqui s'étend Banket une classe hybride (héritage multiple) appelée SBICar:

class Car extends Bank {
  Car() {
    super();
  }
  public void run(){
    System.out.println("99Km/h");
  }
}
class SBICar extends Bank, Car {
  SBICar() {
    super(); //NOTE: compile time ambiguity.
  }
  public void run() {
    System.out.println("99Km/h");
  }
  public void printBankBalance(){
    System.out.println("20k");
  }
}

Dans ce cas (SBICar) ne parviendra pas à créer la chaîne de constructeur ( ambiguïté de compilation ).

Pour les interfaces, cela est autorisé car nous ne pouvons pas en créer un objet.

Pour le nouveau concept defaultet la staticméthode, veuillez vous référer à default dans l'interface .

J'espère que cela résoudra votre requête. Merci.


7

L'implémentation de plusieurs interfaces est très utile et ne pose pas beaucoup de problèmes aux développeurs de langage ni aux programmeurs. C'est donc permis. L'héritage multiple, tout en étant également utile, peut causer de graves problèmes aux utilisateurs ( diamant redouté de la mort ). Et la plupart des choses que vous faites avec l'héritage multiple peuvent également être effectuées par composition ou en utilisant des classes internes. L'héritage multiple est donc interdit car apportant plus de problèmes que de gains.


Quel est le problème avec le «diamant de la mort»?
curiousguy

2
@curiousguy Contenant plus d'un sous-objet de la même classe de base, ambiguïté (remplacement à partir de quelle classe de base utilise), règles compliquées pour résoudre une telle ambiguïté.
Tadeusz Kopec

@curiousguy: Si un framework prévoit que le transtypage d'une référence d'objet vers une référence de type de base préserve l'identité, alors chaque instance d'objet doit avoir exactement une implémentation de toute méthode de classe de base. Si ToyotaCaret les HybridCardeux dérivaient de Caret remplaçaient Car.Drive, et s'ils PriusCarhéritaient des deux mais ne les remplaceraient pasDrive , le système n'aurait aucun moyen d'identifier ce que le virtuel Car.Drivedevrait faire. Les interfaces évitent ce problème en évitant la condition en italique ci-dessus.
supercat du

1
@supercat "le système n'aurait aucun moyen d'identifier ce que devrait faire le Car.Drive virtuel." <- Ou cela pourrait simplement donner une erreur de compilation et vous faire en choisir une explicitement, comme le fait C ++.
Chris Middleton

1
@ChrisMiddleton: une méthode void UseCar(Car &foo); on ne peut pas s'attendre à ce qu'il inclue une désambiguïsation entre ToyotaCar::Driveet HybridCar::Drive(car il ne devrait souvent ni savoir ni se soucier que ces autres types existent même ). Un langage pourrait, comme le fait C ++, exiger que le code ToyotaCar &myCarsouhaitant le transmettre à UseCardoit d'abord être converti en soit HybridCarou ToyotaCar, mais puisque ((Car) (HybridCar) myCar) .Drive` et ((Car)(ToyotaCar)myCar).Drive ferait des choses différentes, cela impliquerait que les upcasts ne préservaient pas l’identité.
supercat

6

Vous pouvez trouver une réponse précise pour cette requête dans la page de documentation d'Oracle sur l' héritage multiple

  1. Héritage multiple d'état: possibilité d'hériter des champs de plusieurs classes

    L'une des raisons pour lesquelles le langage de programmation Java ne vous permet pas d'étendre plus d'une classe est d'éviter les problèmes d'héritage multiple d'état, qui est la possibilité d'hériter des champs de plusieurs classes.

    Si l'héritage multiple est autorisé et lorsque vous créez un objet en instanciant cette classe, cet objet hérite des champs de toutes les superclasses de la classe. Cela causera deux problèmes.

    1. Et si des méthodes ou des constructeurs de différentes super classes instanciaient le même champ?
    2. Quelle méthode ou quel constructeur aura la priorité?
  2. Héritage multiple d'implémentation: possibilité d'hériter des définitions de méthode de plusieurs classes

    Problèmes avec cette approche: nommer les conflits et l' ambiguïté . Si une sous-classe et une superclasse contiennent le même nom de méthode (et la même signature), le compilateur ne peut pas déterminer la version à appeler.

    Mais java prend en charge ce type d'héritage multiple avec les méthodes par défaut , qui ont été introduites depuis la version Java 8. Le compilateur Java fournit des règles pour déterminer la méthode par défaut utilisée par une classe particulière.

    Reportez-vous au post SE ci-dessous pour plus de détails sur la résolution du problème de diamant:

    Quelles sont les différences entre les classes abstraites et les interfaces dans Java 8?

  3. Héritage multiple de type: Capacité d'une classe à implémenter plus d'une interface.

    Comme l'interface ne contient pas de champs modifiables, vous n'avez pas à vous soucier des problèmes qui résultent de l'héritage multiple d'état ici.



4

Java prend en charge l'héritage multiple via des interfaces uniquement. Une classe peut implémenter n'importe quel nombre d'interfaces mais ne peut étendre qu'une seule classe.

L'héritage multiple n'est pas pris en charge car il conduit à un problème de diamant mortel. Cependant, il peut être résolu mais cela conduit à un système complexe, de sorte que l'héritage multiple a été abandonné par les fondateurs de Java.

Dans un livre blanc intitulé «Java: un aperçu» de James Gosling en février 1995 ( lien ) donne une idée des raisons pour lesquelles l'héritage multiple n'est pas pris en charge en Java.

Selon Gosling:

"JAVA omet de nombreuses fonctionnalités rarement utilisées, mal comprises et déroutantes de C ++ qui, d'après notre expérience, apportent plus de problèmes que d'avantages. Cela consiste principalement en une surcharge d'opérateurs (bien qu'il y ait une surcharge de méthode), un héritage multiple et des coercitions automatiques étendues."


le lien n'est pas accessible. Veuillez le vérifier et le mettre à jour.
MashukKhan le

3

Pour la même raison, C # n'autorise pas l'héritage multiple mais vous permet d'implémenter plusieurs interfaces.

La leçon tirée du C ++ avec héritage multiple était qu'il conduisait à plus de problèmes qu'il n'en valait la peine.

Une interface est un contrat de choses que votre classe doit implémenter. Vous n'obtenez aucune fonctionnalité de l'interface. L'héritage vous permet d'hériter des fonctionnalités d'une classe parente (et en héritage multiple, cela peut devenir extrêmement déroutant).

Autoriser plusieurs interfaces vous permet d'utiliser des modèles de conception (comme Adapter) pour résoudre les mêmes types de problèmes que vous pouvez résoudre à l'aide de l'héritage multiple, mais d'une manière beaucoup plus fiable et prévisible.


10
C # n'a pas d'héritage multiple précisément parce que Java ne le permet pas. Il a été conçu beaucoup plus tard que Java. Je pense que le principal problème de l'héritage multiple était la façon dont les gens apprenaient à l'utiliser à gauche et à droite. Le concept selon lequel la délégation dans la plupart des cas est une bien meilleure alternative n’était tout simplement pas là au début et au milieu des années 90. Par conséquent, je me souviens d'exemples, dans les manuels, où la voiture est une roue et une porte et un pare-brise, contre une voiture contient des roues, des portes et un pare-brise. Donc, l'héritage unique à Java était une réaction instinctive à cette réalité.
Alexander Pogrebnyak

2
@AlexanderPogrebnyak: Choisissez deux des trois suivants: (1) Autoriser les transtypages préservant l'identité d'une référence de sous-type à une référence de supertype; (2) Permettre à une classe d'ajouter des membres publics virtuels sans recompiler les classes dérivées; (3) Permettre à une classe d'hériter implicitement des membres virtuels de plusieurs classes de base sans avoir à les spécifier explicitement. Je ne pense pas qu'il soit possible pour aucune langue de gérer les trois éléments ci-dessus. Java a opté pour les n ° 1 et 2, et C # a emboîté le pas. Je crois que C ++ n'adopte que le # 3. Personnellement, je pense que les n ° 1 et 2 sont plus utiles que les n ° 3, mais d'autres peuvent différer.
supercat du

@supercat "Je ne crois pas qu'il soit possible pour aucun langage de gérer les trois éléments ci-dessus" - si les décalages des données membres sont déterminés au moment de l'exécution, plutôt qu'au moment de la compilation (comme ils le sont dans "l'ABI non fragile d'Objective-C "), et / ou une base par classe (c'est-à-dire que chaque classe concrète a sa propre table de décalage des membres), alors je pense que les 3 objectifs peuvent être atteints.
The Paramagnetic Croissant

@TheParamagneticCroissant: Le problème sémantique majeur est # 1. Si D1et les D2deux héritent de B, et chacun remplace une fonction f, et si objest une instance d'un type Squi hérite des deux D1et D2mais ne remplace pas f, alors la conversion d'une référence en Sen D1devrait donner quelque chose dont futilise le D1remplacement, et la conversion en Bne devrait pas changez cela. De même, le cast d'une référence Svers D2devrait produire quelque chose dont futilise le D2remplacement, et le cast vers Bne devrait pas changer cela. Si une langue n'avait pas besoin d'autoriser l'ajout de membres virtuels ...
supercat

1
@TheParamagneticCroissant: Cela pourrait, et ma liste de choix a été un peu trop simplifiée pour tenir dans un commentaire, mais le report à l'exécution rend impossible pour l'auteur de D1, D2 ou S de savoir quels changements ils peuvent faire sans casser consommateurs de leur classe.
supercat du

2

Puisque ce sujet n'est pas proche, je publierai cette réponse, j'espère que cela aidera quelqu'un à comprendre pourquoi java n'autorise pas l'héritage multiple.

Considérez la classe suivante:

public class Abc{

    public void doSomething(){

    }

}

Dans ce cas, la classe Abc ne prolonge rien non? Pas si vite, cette classe étend implicitement la classe Object, classe de base qui permet à tout de fonctionner en java. Tout est un objet.

Si vous essayez d'utiliser la classe ci - dessus , vous verrez que votre IDE vous permettent d'utiliser des méthodes telles que : equals(Object o), toString(), etc, mais vous ne l' avez pas déclaré ces méthodes, ils sont venus de la classe de baseObject

Tu pourrais essayer:

public class Abc extends String{

    public void doSomething(){

    }

}

C'est bien, car votre classe ne s'étendra pas implicitement Objectmais s'étendra Stringparce que vous l'avez dit. Considérez le changement suivant:

public class Abc{

    public void doSomething(){

    }

    @Override
    public String toString(){
        return "hello";
    }

}

Maintenant, votre classe retournera toujours "hello" si vous appelez toString ().

Imaginez maintenant la classe suivante:

public class Flyer{

    public void makeFly(){

    }

}

public class Bird extends Abc, Flyer{

    public void doAnotherThing(){

    }

}

Encore une fois la classe Flyerimplicite s'étend Object qui a la méthode toString(), n'importe quelle classe aura cette méthode puisqu'elles s'étendent toutes Objectindirectement, donc, si vous appelez à toString()partir de Bird, quel toString()Java devrait utiliser? De Abcou Flyer? Cela se produira avec n'importe quelle classe qui essaie d'étendre deux classes ou plus, pour éviter ce genre de "collision de méthodes", ils ont construit l'idée d' interface , en gros vous pourriez les considérer comme une classe abstraite qui n'étend pas Object indirectement . Comme ils sont abstraits, ils devront être implémentés par une classe, ce qui est un objet(vous ne pouvez pas instancier une interface seule, ils doivent être implémentés par une classe), donc tout continuera à fonctionner correctement.

Pour différer les classes des interfaces, le mot clé implements était réservé uniquement aux interfaces.

Vous pouvez implémenter n'importe quelle interface que vous aimez dans la même classe puisqu'elles n'étendent rien par défaut (mais vous pouvez créer une interface qui étend une autre interface, mais encore une fois, l'interface "père" n'étend pas Object "), donc une interface est juste une interface et ils ne souffriront pas de " colissions de signatures de méthodes ", s'ils le font, le compilateur vous lancera un avertissement et vous devrez juste changer la signature de la méthode pour la corriger (signature = nom de la méthode + paramètres + type de retour) .

public interface Flyer{

    public void makeFly(); // <- method without implementation

}

public class Bird extends Abc implements Flyer{

    public void doAnotherThing(){

    }

    @Override
    public void makeFly(){ // <- implementation of Flyer interface

    }

    // Flyer does not have toString() method or any method from class Object, 
    // no method signature collision will happen here

}

1

Parce qu'une interface n'est qu'un contrat. Et une classe est en fait un conteneur de données.


La difficulté fondamentale de l'héritage multiple est la possibilité qu'une classe hérite d'un membre via plusieurs chemins qui l'implémentent différemment, sans fournir sa propre implémentation de substitution. L'héritage d'interface évite cela car le seul endroit où les membres d'interface peuvent être implémentés est dans les classes, dont les descendants seront limités à l'héritage unique.
supercat

1

Par exemple deux classes A, B ayant la même méthode m1 (). Et la classe C étend à la fois A, B.

 class C extends A, B // for explaining purpose.

Maintenant, la classe C recherchera la définition de m1. Tout d'abord, il cherchera en classe s'il n'a pas trouvé, puis il vérifiera la classe des parents. Les deux A, B ayant la définition Donc ici une ambiguïté se produit quelle définition doit choisir. Donc JAVA NE PREND PAS EN CHARGE DES HÉRITÉS MULTIPLES.


que diriez-vous de faire le compilateur java donne au compilateur si les mêmes méthodes ou variables définies dans les deux classes parentes afin que nous puissions changer le code ...
siluveru kiran kumar

1

Java ne prend pas en charge l'héritage multiple pour deux raisons:

  1. En java, chaque classe est un enfant de Objectclasse. Lorsqu'elle hérite de plus d'une super classe, la sous-classe obtient l'ambiguïté pour acquérir la propriété de la classe Object.
  2. En java, chaque classe a un constructeur, si nous l'écrivons explicitement ou pas du tout. La première instruction appelle super()pour invoquer le constructeur de la classe supper. Si la classe a plus d'une super classe, elle devient confuse.

Ainsi, lorsqu'une classe s'étend à partir de plus d'une super classe, nous obtenons une erreur de compilation.


0

Prenons par exemple le cas où la classe A a une méthode getSomething et la classe B une méthode getSomething et la classe C étend A et B. Que se passerait-il si quelqu'un appelait C.getSomething? Il n'existe aucun moyen de déterminer la méthode à appeler.

Les interfaces spécifient simplement quelles méthodes une classe d'implémentation doit contenir. Une classe qui implémente plusieurs interfaces signifie simplement que la classe doit implémenter les méthodes de toutes ces interfaces. Whci n'entraînerait aucun problème comme décrit ci-dessus.


2
" Que se passerait-il si quelqu'un appelait C.getSomething? " C'est une erreur en C ++. Problème résolu.
curiousguy

C'était le point ... c'était un contre-exemple que je pensais clair. Je faisais remarquer qu'il n'y a aucun moyen de déterminer quelle méthode get something devrait être appelée. En remarque également, la question était liée à java et non à c ++
John Kane

Je suis désolé de ne pas comprendre votre argument. De toute évidence, il existe une ambiguïté dans certains cas avec l'IM. En quoi est-ce un contre-exemple? Qui a prétendu que l'IM ne provoquait jamais d'ambiguïté? " Également en remarque, la question était liée à java et non à c ++ " Alors?
curiousguy

J'essayais juste de montrer pourquoi cette ambiguïté existe et pourquoi ce n'est pas le cas avec les interfaces.
John Kane

Oui, MI peut entraîner des appels ambigus. Alors peut surcharger. Java devrait donc supprimer la surcharge?
curiousguy

0

Considérez un scénario où Test1, Test2 et Test3 sont trois classes. La classe Test3 hérite des classes Test2 et Test1. Si les classes Test1 et Test2 ont la même méthode et que vous l'appelez à partir d'un objet de classe enfant, il y aura ambiguïté pour appeler la méthode de la classe Test1 ou Test2, mais il n'y a pas d'ambiguïté pour l'interface car dans l'interface aucune implémentation n'est là.


0

Java ne prend pas en charge l'héritage multiple, l'héritage multi-chemins et l'héritage hybride en raison d'un problème d'ambiguïté:

 Scenario for multiple inheritance: Let us take class A , class B , class C. class A has alphabet(); method , class B has also alphabet(); method. Now class C extends A, B and we are creating object to the subclass i.e., class C , so  C ob = new C(); Then if you want call those methods ob.alphabet(); which class method takes ? is class A method or class B method ?  So in the JVM level ambiguity problem occurred. Thus Java does not support multiple inheritance.

héritage multiple

Lien de référence: https://plus.google.com/u/0/communities/102217496457095083679


0

de manière simple, nous le savons tous, nous pouvons hériter (étendre) une classe, mais nous pouvons implémenter tellement d'interfaces ... c'est parce que dans les interfaces, nous ne donnons pas d'implémentation, disons simplement la fonctionnalité. supposons que si java peut étendre autant de classes et que celles-ci ont les mêmes méthodes .. à ce stade, si nous essayons d'appeler une méthode de super classe dans la sous-classe, quelle méthode suppose d'exécuter ??, le compilateur devient confus exemple: - essayez d'étendre plusieurs mais dans interfaces ces méthodes n'ont pas de corps, nous devrions les implémenter dans la sous-classe .. essayez plusieurs implémentations donc pas de soucis ..


1
Vous pouvez simplement poster ici ces exemples. Sans cela, cela ressemble à un bloc de texte à une question de 9 ans à laquelle on répond cent fois.
Pochmurnik

-1

* C'est une réponse simple puisque je suis débutant en Java *

Considérez qu'il existe trois classes X, Yet Z.

Nous héritons donc de X extends Y, Z And both Yet avons Zune méthode alphabet()avec le même type de retour et les mêmes arguments. Cette méthode alphabet()en Ydit afficher premier alphabet et alphabet méthode Zdit affichage dernier alphabet . Alors, voici l'ambiguïté quand alphabet()est appelé par X. Que ce soit pour afficher le premier ou le dernier alphabet ??? Ainsi, java ne prend pas en charge l'héritage multiple. Dans le cas des interfaces, considérez Yet Zcomme des interfaces. Donc les deux contiendront la déclaration de méthode alphabet()mais pas la définition. Il ne dira pas s'il faut afficher le premier alphabet ou le dernier alphabet ou quoi que ce soit, mais déclarera simplement une méthodealphabet(). Il n'y a donc aucune raison de soulever l'ambiguïté. Nous pouvons définir la méthode avec tout ce que nous voulons dans la classe X.

Donc en un mot, dans Interfaces la définition se fait après implémentation donc pas de confusion.

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.