Vererbung - Polymorphie

[missprincess96]

Hallo zusammen,

ich hänge aktuell bei der Aufgabe fest.

Laut meinem Verständnis:
In beiden Fällen wird im ersten Schritt ein Datentyp der Superklasse verwendet um ein Objekt der Subklasse zu instanziieren. Die Methoden ist im Fall 1 bezüglich des Parameters abgeändert, führt aber dennoch zu keinem Fehler.

Mein Problem ist nun die jeweils zweite Zeile nachzuvollziehen was hier genau passiert x1.m(new B());
y1.m(new B());

Könntet ihr mir bitte hier weiterhelfen.
Vielen Dank.

 

[httpdigest]

Bei Fall 1 wird mit X1 x1 = new X2(); ein Objekt des Typs X2 erzeugt und einer Variablen des (statischen) Typs X1 zugewiesen. Das Objekt, was sich dann in der Variablen x1 befindet, hat also den (dynamischen) Laufzeittyp X2. Und, weil X2 von X1 erbt, kann ein Ausdruck des Typs X2 (nämlich new X2()) auch einer Variablen des Typs X1 zugewiesen werden.

Anschließend wird mit x1.m(new B()); eine Methode m auf dem Objekt, welches sich in der Variablen x1 befindet, aufgerufen. Hier ist allerdings ein Kniff in der Aufgabe: Sowohl die Klasse X1 als auch die davon abgeleitete Klasse X2 definieren eine Methode m.
Aber X1 definiert sie mit dem (statischen) Parametertyp A und X2 definiert sie mit dem unterschiedlichen (statischen) Parametertyp B.
Beim Aufruf x1.m(new B()); "sieht" der Compiler aufgrund des statischen Typs X1 der Variablen x1, über die ja die Methode m aufgerufen wird, nur die Methode m(A):void aus X1 und muss jetzt annehmen, dass erstmal diese Methode gemeint ist, also die in X1.
Zusätzlich muss man jetzt wissen, dass (in Java bzw. der JVM) Methoden nicht überschrieben werden, wenn ihre Parametertypen nicht exakt übereinstimmen. Die Methode m wird also in X2 nicht überschrieben, sondern X2 definiert eine vollkommen neue/unabhängige Methode m, die nichts mit der gleichnamigen Methode in X1 zu tun hat.
Somit wird also, obwohl der (dynamische) Laufzeit-Typ des Objektes in x1 eigentlich X2 ist und X2 ja eigentlich eine Methode m(B):void definiert und das Argument für den Methodenaufruf x1.m(new B()); ja auch ein B ist, letztlich die Methode X1.m(A):void in X1 aufgerufen mit einem B als Argument (was ja funktioniert, weil jedes B auch immer ein A ist).

 

[missprincess96]

Bei Fall 1 wird mit X1 x1 = new X2(); ein Objekt des Typs X2 erzeugt und einer Variablen des (statischen) Typs X1 zugewiesen. Das Objekt, was sich dann in der Variablen x1 befindet, hat also den (dynamischen) Laufzeittyp X2. Und, weil X2 von X1 erbt, kann ein Ausdruck des Typs X2 (nämlich new X2()) auch einer Variablen des Typs X1 zugewiesen werden.

Anschließend wird mit x1.m(new B()); eine Methode m auf dem Objekt, welches sich in der Variablen x1 befindet, aufgerufen. Hier ist allerdings ein Kniff in der Aufgabe: Sowohl die Klasse X1 als auch die davon abgeleitete Klasse X2 definieren eine Methode m.
Aber X1 definiert sie mit dem (statischen) Parametertyp A und X2 definiert sie mit dem unterschiedlichen (statischen) Parametertyp B.
Beim Aufruf x1.m(new B()); "sieht" der Compiler aufgrund des statischen Typs X1 der Variablen x1, über die ja die Methode m aufgerufen wird, nur die Methode m(A):void aus X1 und muss jetzt annehmen, dass erstmal diese Methode gemeint ist, also die in X1.
Zusätzlich muss man jetzt wissen, dass (in Java bzw. der JVM) Methoden nicht überschrieben werden, wenn ihre Parametertypen nicht exakt übereinstimmen. Die Methode m wird also in X2 nicht überschrieben, sondern X2 definiert eine vollkommen neue/unabhängige Methode m, die nichts mit der gleichnamigen Methode in X1 zu tun hat.
Somit wird also, obwohl der (dynamische) Laufzeit-Typ des Objektes in x1 eigentlich X2 ist und X2 ja eigentlich eine Methode m(B):void definiert und das Argument für den Methodenaufruf x1.m(new B()); ja auch ein B ist, letztlich die Methode X1.m(A):void in X1 aufgerufen mit einem B als Argument (was ja funktioniert, weil jedes B auch immer ein A ist).

Vielen Dank für die ausführliche und verständliche Antwort !

 

[IchWeißEs]

Danke für die super Erklärung, @httpdigest ! 😊

Ich wollte gerade anfangen, zu schreiben, aber du hast schon alles abgedeckt bzw. bedient.

 

[IchWeißEs]

Ach, vielleicht noch eine Anmerkung ... Wäre der Fall umgekehrt, das heißt die Klasse X1 definiert eine Methode m(B):void und die Klasse X2 definiert eine Methode m(A):void, so würde X2 die Methode m aus X1 überschreiben. Dabei würde hier die ... (muss ich aber, glaube ich, in der JLS nachlesen) "Parameter-Erweiterung/-Inferenz" greifen.

Aber so, wie es gegeben ist, wird m nur "verdeckt".

 

[IchWeißEs]

Overriding and Hiding Methods (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance)

docs.oracle.com

An instance method in a subclass with the same signature (name, plus the number and the type of its parameters) and return type as an instance method in the superclass overrides the superclass's method.


The ability of a subclass to override a method allows a class to inherit from a superclass whose behavior is "close enough" and then to modify behavior as needed. The overriding method has the same name, number and type of parameters, and return type as the method that it overrides. An overriding method can also return a subtype of the type returned by the overridden method. This subtype is called a covariant return type.

Eine Instanzmethode in einer Unterklasse mit der gleichen Signatur (Name sowie Anzahl und Typ der Parameter) und dem gleichen Rückgabetyp wie eine Instanzmethode in der Oberklasse überschreibt die Methode der Oberklasse.

Die Fähigkeit einer Unterklasse, eine Methode zu überschreiben, ermöglicht es einer Klasse, von einer Oberklasse zu erben, deren Verhalten "nahe genug" ist, und dann das Verhalten nach Bedarf zu ändern. Die überschreibende Methode hat denselben Namen, dieselbe Anzahl und denselben Typ von Parametern sowie denselben Rückgabetyp wie die Methode, die sie überschreibt. Eine überschreibende Methode kann auch einen Subtyp des Typs zurückgeben, der von der überschreibenden Methode zurückgegeben wird. Dieser Subtyp wird als kovarianter Rückgabetyp bezeichnet.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Die richtige Bezeichnung wäre also, glaube ich, kovarianter Parametertyp.

Edit: Ups, das war leider falsch: https://stackoverflow.com/questions...ws-to-have-covariant-return-types-but-not-cov

 

[IchWeißEs]

Ein A wäre ja auch kein B. 🥴 Sorry, nicht richtig aufgepasst. Quintessenz: Der Rückgabetyp überschriebener Methoden darf kovariant sein, die Parameter aber nicht - andernfalls liegt keine Überschreibung vor.

 

[missprincess96]

Bei Fall 1 wird mit X1 x1 = new X2(); ein Objekt des Typs X2 erzeugt und einer Variablen des (statischen) Typs X1 zugewiesen. Das Objekt, was sich dann in der Variablen x1 befindet, hat also den (dynamischen) Laufzeittyp X2. Und, weil X2 von X1 erbt, kann ein Ausdruck des Typs X2 (nämlich new X2()) auch einer Variablen des Typs X1 zugewiesen werden.

Anschließend wird mit x1.m(new B()); eine Methode m auf dem Objekt, welches sich in der Variablen x1 befindet, aufgerufen. Hier ist allerdings ein Kniff in der Aufgabe: Sowohl die Klasse X1 als auch die davon abgeleitete Klasse X2 definieren eine Methode m.
Aber X1 definiert sie mit dem (statischen) Parametertyp A und X2 definiert sie mit dem unterschiedlichen (statischen) Parametertyp B.
Beim Aufruf x1.m(new B()); "sieht" der Compiler aufgrund des statischen Typs X1 der Variablen x1, über die ja die Methode m aufgerufen wird, nur die Methode m(A):void aus X1 und muss jetzt annehmen, dass erstmal diese Methode gemeint ist, also die in X1.
Zusätzlich muss man jetzt wissen, dass (in Java bzw. der JVM) Methoden nicht überschrieben werden, wenn ihre Parametertypen nicht exakt übereinstimmen. Die Methode m wird also in X2 nicht überschrieben, sondern X2 definiert eine vollkommen neue/unabhängige Methode m, die nichts mit der gleichnamigen Methode in X1 zu tun hat.
Somit wird also, obwohl der (dynamische) Laufzeit-Typ des Objektes in x1 eigentlich X2 ist und X2 ja eigentlich eine Methode m(B):void definiert und das Argument für den Methodenaufruf x1.m(new B()); ja auch ein B ist, letztlich die Methode X1.m(A):void in X1 aufgerufen mit einem B als Argument (was ja funktioniert, weil jedes B auch immer ein A ist).

Ich habe mir nochmal ein wenig weitere Gedanken gemacht, kann jedoch den Punkt "was ja funktioniert, weil jedes B auch immer ein A ist", im letzten Satz noch nicht ganz nachvollziehen. Kannst du diesen bitte ein erläutern. Vielen Dank.

Edit: Ich glaube ich habe es mir soeben selbst erklären können. Ganz links in der Grafik wird ja B von A vererbt. Somit ist jedes B auch ein A. Sorry!

 

[IchWeißEs]

Somit ist jedes B auch ein A

wahr

 

[temi]

Ich habe mir nochmal ein wenig weitere Gedanken gemacht, kann jedoch den Punkt "was ja funktioniert, weil jedes B auch immer ein A ist", im letzten Satz noch nicht ganz nachvollziehen. Kannst du diesen bitte ein erläutern. Vielen Dank.

Vererbung kann man als eine "ist ein"-Beziehung verstehen. Wenn also B von A erbt, dann ist B ein A. Oder etwas plakativer: Wenn "Affe" von "Tier" erbt, dann ist "Affe" ein "Tier".

 

[missprincess96]

Bei Fall 1 wird mit X1 x1 = new X2(); ein Objekt des Typs X2 erzeugt und einer Variablen des (statischen) Typs X1 zugewiesen. Das Objekt, was sich dann in der Variablen x1 befindet, hat also den (dynamischen) Laufzeittyp X2. Und, weil X2 von X1 erbt, kann ein Ausdruck des Typs X2 (nämlich new X2()) auch einer Variablen des Typs X1 zugewiesen werden.

Anschließend wird mit x1.m(new B()); eine Methode m auf dem Objekt, welches sich in der Variablen x1 befindet, aufgerufen. Hier ist allerdings ein Kniff in der Aufgabe: Sowohl die Klasse X1 als auch die davon abgeleitete Klasse X2 definieren eine Methode m.
Aber X1 definiert sie mit dem (statischen) Parametertyp A und X2 definiert sie mit dem unterschiedlichen (statischen) Parametertyp B.
Beim Aufruf x1.m(new B()); "sieht" der Compiler aufgrund des statischen Typs X1 der Variablen x1, über die ja die Methode m aufgerufen wird, nur die Methode m(A):void aus X1 und muss jetzt annehmen, dass erstmal diese Methode gemeint ist, also die in X1.
Zusätzlich muss man jetzt wissen, dass (in Java bzw. der JVM) Methoden nicht überschrieben werden, wenn ihre Parametertypen nicht exakt übereinstimmen. Die Methode m wird also in X2 nicht überschrieben, sondern X2 definiert eine vollkommen neue/unabhängige Methode m, die nichts mit der gleichnamigen Methode in X1 zu tun hat.
Somit wird also, obwohl der (dynamische) Laufzeit-Typ des Objektes in x1 eigentlich X2 ist und X2 ja eigentlich eine Methode m(B):void definiert und das Argument für den Methodenaufruf x1.m(new B()); ja auch ein B ist, letztlich die Methode X1.m(A):void in X1 aufgerufen mit einem B als Argument (was ja funktioniert, weil jedes B auch immer ein A ist).

Was ich noch nicht ganz nachvollziehen kann ist, wieso wird hier im ersten Fall die Methode aus X1 aufgerufen, wenn die zweite Methode ja eigentlich spezifischer ist, da Sie B erwartet. Liegt es einfach nur daran, weil die Methode nicht überschrieben wird und auch gleichzeitig nicht die Methode aus X2 kennt?
Im zweiten Fall wird ja die Methode von Y2 aufgerufen, da diese die letzte überschreibende Methode entlang der Vererbungshierachie ist.

 

[IchWeißEs]

da diese die letzte überschreibende Methode entlang der Vererbungshierachie ist

Die Vererbungshierarchie ist für die Determination egal. Wichtig ist, welchen dynamischen Laufzeittyp eine Variable hat - dann wird ab dieser Klasse der Vererbungshierarchie nach oben gefolgt.

Bei Fall 1 wird nur nichts überschrieben. X2 hat die gewünschte Methode schlicht nicht.

 

[IchWeißEs]

In der Politik würde man das Subsidiaritätsprinzip nennen, in der Programmierung aber einfach Polymorphie.

 

[temi]

wieso wird hier im ersten Fall die Methode aus X1 aufgerufen

Um es mal ganz platt auszudrücken: Weil die Variable "x1" vom Typ "X1" ist.

 

[IchWeißEs]

Um es mal ganz platt auszudrücken: Weil die Variable "x1" vom Typ "X1" ist.

Das ist nicht korrekt. Der Typ ist X2, da X2 die gesuchte Methode aber nicht hat, wird die der ableitenden Klasse genommen. Genau, wie es auch @httpdigest beschrieben hat.

 

[temi]

Das ist nicht korrekt. Der Typ ist X2, da X2 die gesuchte Methode aber nicht hat, wird die der ableitenden Klasse genommen. Genau, wie es auch @httpdigest beschrieben hat.

Stimmt auch nicht ganz. Der statische Typ ist X1, aber in der Variablen ist eine Referenz auf ein X2 gespeichert (was geht, weil es wegen Vererbung ein X1 "ist").

Du hast aber Recht, dass die Methode m(A) von X2 nicht überschrieben wird und darum nicht verwendet wird. Würde sie überschrieben werden, dann würde auch die Methode von X2 verwendet werden.

Um die Verwirrung komplett zu machen: Man könnte den Compiler durch Casting dazu bringen, die Methode von X2 zu verwenden.

((X2) x1).m(new B());

 

[IchWeißEs]

die Methode von X2 zu verwenden

die aber "nur" eine andere Methode mit zufällig gleichem Namen ist...

 

[temi]

die aber "nur" eine andere Methode mit zufällig gleichem Namen ist...

Das stimmt. Ich weiß nicht, ob man in dem Fall von "Überladen" sprechen kann oder ob das nur innerhalb einer Klasse so genannt wird.

public class Main
{
    public static void main(String[] args) {
        X1 x1 = new X2();
        
        x1.m(new A()); // X1
        x1.m(new B()); // X1
        ((X2) x1).m(new B()); // X2
        
        x1.n(new A()); // X2
        x1.n(new B()); // X2
    
        
        X2 x2 = new X2();
        
        x2.m(new A()); // X1
        x2.m(new B()); // X2
    }
}

class X1 {
    
    void m(A a) {
        System.out.println("X1");
    }
    
    void n(A a) {
        System.out.println("X1");
    }
}

class X2 extends X1 {
    
    void m(B b) {
        System.out.println("X2");
    }
    
    @Override
    void n(A a) {
        System.out.println("X2");
    }
}

class A {}

class B extends A {}

 

[IchWeißEs]

Aber irgendwie... bin ich jetzt komplett verwirrt...

 

[mihe7]

ob man in dem Fall von "Überladen" sprechen kann

Warum nicht? X2 überlädt die Methode, die sie von X1 erbt.

If two methods of a class (whether both declared in the same class, or both inherited by a class, or one declared and one inherited) have the same name but signatures that are not override-equivalent, then the method name is said to be overloaded.

 

[IchWeißEs]

die sie von X1 erbt

eben nicht. X2 erbt nicht, sondern überlädt nur.

 

[KonradN]

eben nicht. X2 erbt nicht, sondern überlädt nur.

Sind Dir die Begriffe klar? Was bedeutet erben? Was bedeutet überladen?

Das sind die Übersetzungen von inherit und overload.

Und bei der JLS dann mit "eben nicht" zu antworten ist irgendwie doch etwas dubios

 

[IchWeißEs]

Und bei der JLS dann mit "eben nicht" zu antworten ist irgendwie doch etwas dubios

Nö. Ganz im Gegenteil, das ist genau das was dort steht.

Bist du des Lesens mächtig?

 

[mihe7]

eben nicht. X2 erbt nicht, sondern überlädt nur.

Wo kommt die Methode denn her, die X2 überlädt?

 

[Marinek]

Leute, Tobias, 100er Account und ihr diskutiert.....

 

[IchWeißEs]

Wo kommt die Methode denn her, die X2 überlädt?

Es ist klar definiert, wann geerbt wird und wann nicht. Wenn du nochmal in #6 schauen möchtest.

 

[IchWeißEs]

Leute, Tobias, 100er Account und ihr diskutiert.....

Jo, Martin oder Marinek... oder wie auch immer man dich nennt, Holzkopf oder so, darfst du so spät noch wach sein?

 

[KonradN]

@mihe7 Was ist nach der Reaktion deine Erwartung oder Hoffnung? Nach den massiven Aussagen wird wohl kaum eine Aussage kommen a.la. „Ups, habe ich falsch verstanden“ oder so.

Als da #23 kam wollte ich schon eine ausführliche Erläuterung schreiben aber dann kam direkt #24 hinterher womit klar war, dass ich das gleich abbrechen konnte.

Oder habe ich da etwas missverstanden? Kannst mir auch gerne privat schreiben, falls meine Antwort #22 evtl. ungeschickt war. Ich nehme da konstruktive Kritik sehr gerne entgegen!

Aber jetzt die Antwort zeigt den Denkfehler: in #6 geht es um das überschreiben… das es bei erben / überladen nicht um das überschreiben geht, hat er schlicht nicht mitbekommen … oder siehst du das anders?

 

[mihe7]

Es ist klar definiert, wann geerbt wird und wann nicht. Wenn du nochmal in #6 schauen möchtest.

Kann es sein, dass Du Dich im Code verschaut hast? In dem Beispiel von @temi wird n(A) von X1 in X2 überschrieben, das wäre der Punkt aus #6 (s. JLS 8.4.8.1). Dagegen wird m(A) an X2 vererbt (JLS 8.4.8) und mit m(B) in X2 überladen (JLS 8.4.9).

 

[KonradN]

Für alle, die hier über den Thread stolpern und dann leicht verwirrt werden möchte ich einfach einmal ein paar Punkte deutlich machen.


Also es gibt hier jetzt 3 Punkte, die betrachtet werden müssen:

a) Das Thema Inheritance. Wenn eine Klasse von einer anderen erbt, dann ist klar vorgegeben, was von dieser Klasse geerbt wird und was nicht.
b) Overriding - Eine Methode kann überschrieben werden. Laut Definition der JLS wird die Methode dann nicht geerbt sondern überschrieben.
c) Overloading - Es kann mehrere Methoden mit gleichem Namen aber unterschiedlichen Signaturen geben. Und da gibt es dann Regeln, die gelten müssen.

Die Bedingungen sind in Chapter 8. Classes (oracle.com) auch recht deutlich:


Inheritance (Methoden)
Eine Methode wird geerbt wenn:
A class C inherits from its direct superclass type D all concrete methods m (both static and instance) for which all of the following are true:

• m is a member of D.
• m is public, protected, or declared with package access in the same package as C.
• No method declared in C has a signature that is a subsignature (§8.4.2) of the signature of m as a member of D.

Also die Methode muss in der übergeordneten Klasse sein und sie muss public protected oder package private sein mit beiden Klassen im gleichen Package.
Und sie darf nicht überschrieben worden sein - sprich die Signatur darf keine "subsignature" sein.

Overriding
Beim Overriding ist es dann sehr ähnlich - nur der letzte Punkt ist eigentlich negiert sowie leichte Veränderungen bezüglich der Zugriffsrechte:
An instance method mC declared in or inherited by class C, overrides from C another method mA declared in class A, iff all of the following are true:

• C is a subclass of A.
• C does not inherit mA.
• The signature of mC is a subsignature (§8.4.2) of the signature of mA as a member of the supertype of C that names A.
• One of the following is true:
  • mA is public.
  • mA is protected.
  • mA is declared with package access in the same package as C, and either C declares mC or mA is a member of the direct superclass type of C.
  • mA is declared with package access and mC overrides mA from some superclass of C.
  • mA is declared with package access and mC overrides a method m' from C (m' distinct from mC and mA), such that m' overrides mA from some superclass of C.

If mC is non-abstract and overrides from C an abstract method mA, then mC is said to implement mA from C.

Dann kommt als letzter Fall noch das Hiding, das hier im Thread noch nicht angesprochen wurde und das führe ich jetzt nicht weiter aus.


Overloading
Dann hatten wir noch als weiteren Punkt das Overloading - das Überladen von Methoden. Das hat mit Inheritance wenig zu tun:
Overloading ist einfach, dass es mehrere Methoden geben kann mit gleichem Namen aber mit unterschiedlichen Signaturen. Was da für Regeln gelten ist dann in der JLS im Detail erläutert. Dabei spielt es aber keine Rolle, woher die Methoden kommen: Sie können aus der übergeordneten Klasse geerbt worden sein oder die Methoden sind in der Klasse selbst geschrieben worden (und dann können sie ggf. eine vorhandene Methode überschreiben oder verstecken). Das spielt alles keine Rolle - wichtig sind lediglich die Regeln, die da dann bezüglich der Signaturen gelten.

 

[mihe7]

@mihe7 Was ist nach der Reaktion deine Erwartung oder Hoffnung?

Debugging.

 

[IchWeißEs]

Kann es sein, dass Du Dich im Code verschaut hast? In dem Beispiel von @temi wird n(A) von X1 in X2 überschrieben, das wäre der Punkt aus #6 (s. JLS 8.4.8.1). Dagegen wird m(A) an X2 vererbt (JLS 8.4.8) und mit m(B) in X2 überladen (JLS 8.4.9).

Es ging darum, dass die Methode m aus X1 nicht an die Methode m aus X2 vererbt wird, sondern X2 m überlädt.

Vererbung, Überladen und Überschreiben sind immer bilateral, nie unilateral. Man kann nicht sagen, eine Methode ist x, y oder z - ohne anzugeben, zu welcher anderen Methode sie x', y' oder z' ist.

Ihr werft hier jetzt wild Begriffe durcheinander, das bringt niemandem etwas. Man kann nicht sagen, A#m verhält sich zu einer fiktiven Methode B#m' so oder so, da sich B#m' zu einer realen Methode B#m so oder so verhält. Man beschreibt das, was gegeben ist - oder lässt es sein.

Insofern bin ich dann mal weg.

 

[KonradN]

Es ging darum, dass die Methode m aus X1 nicht an die Methode m aus X2 vererbt wird, sondern X2 m überlädt.

Es geh darum, dass Du Unsinn schreibst und dass die JLS eben genau etwas anderes schreibt.

Eine "überladene Methode m" bedeutet, dass es zwei Methoden m gibt - mit unterschiedlicher Signatur.
Und X2 hat eine Methode m - woher kommt dann die zweite?
Ja, die erbt X2 von X1, da eben die genannten Bedingungen zutreffen.

Aber das immer und immer wieder zu wiederholen ist vergeudete Lebenszeit - daher habe ich mich in den letzten Posts direkt einmal an @mihe7 und einmal an Andere, die über den Thread stolpern sollten, gewendet. Du hast es nicht verstanden, bist auch nicht bereit, Deine Aussagen zu hinterfragen. Daher habe ich akzeptiert, dass Du eine andere, mit der JLS nicht vereinbare, Sichtweise hast. Aber das ist ok für mich. Dann muss man halt einmal schreiben, wie es richtig ist, dabei die JLS anführen und gut ist es.

 

[temi]

Insofern bin ich dann mal weg.

Wie wahr...

 

[mihe7]

Es ging darum, dass die Methode m aus X1 nicht an die Methode m aus X2 vererbt wird, sondern X2 m überlädt.

Nehmen wir mal an:

public class Test {
    public static class A {}
    public static class B extends A {}

    public static class X1 {
        public void m(A a) {
            System.out.println("m(A) aus X1");
        }
    }

    public static class X2 extends X1 {
    }

    public static void main(String[] args) {
        X2 x = new X2();
        x.m(new A());
        x.m(new B());
    }
}

Sind wir uns einig, dass die Ausgabe

m(A) aus X1
m(A) aus X1

sein wird, weil die Methode m(A) an X2 vererbt wird?

 

[KonradN]

Ich fürchte, deine Debug-Session existiert nicht mehr, da ein BOFH das zu debuggende Subjekt entfernt hat (Evtl. hast Du Dich beschwert, dass Deine Quota zu niedrig ist und daher wurde so Platz geschaffen?).

 

[missprincess96]

Hallo zusammen, ich würde gerne nochmal in wenigen Worten niederlegen wie ich jetzt die Lösung nachvollziehe:
Im Fall 1 wird die erste Methode aufgerufen, da X2 eine andere Methode verwendet (sowie diese nicht kennt) und diese nicht von X1 überschrieben. B ist auch ein A also passt das.
Im Fall 2 wird die Methode überschrieben, deshalb wird die letzte der Vererbungshierachie aufgerufen.

Ist dies so korrekt?

 

[KonradN]

Ja, die Formulierung ist so in meinen Augen korrekt.