Vererbung und Polymorphie

[trunkz0r]

Ich hoffe, das ist das richtige Forum, wenn nicht bitte verschieben

Die Grundprinzipien von Vererbung und Polymorphie sind mir klar.
Allerdings gibt es da ein Phänomen, das ich mir nicht erklären kann. Am besten ich erklärs mit nem Beispielcode:

Es gibt 3 Klassen, eine Vaterklasse A, eine Unterklasse B und eine auszuführende Klasse C:
[highlight=Java]public class A{
public void test(A a){
System.out.println("Methode in A wurde aufgerufen");
}
}
[/highlight]
[highlight=Java]public class B extends A{
public void test(B b){
System.out.println("Methode in B wurde aufgerufen");
}
}
[/highlight]
[highlight=Java]public class C{
public static void main(String[] args){
A ref1 = new B();
B ref2 = new B();
ref1.test(ref2);
}
}
[/highlight]

Was ich daran nicht verstehe, ist wieso die Methode in A aufgerufen wird. Mir ist klar, dass wegen der unterschiedlichen Signatur nichts überschrieben wird.
Eine Möglichkeit wäre, dass, weil ref1 eine Variable von Typ A ist, das ganze implizit zu A gecastet wird. Dann würden doch aber gar keine Funktionen aus B zur Verfügung stehen, was aber nicht der Fall ist (wenn ich die Methoden z.B. überschreiben lasse, indem ich die Parameter wegnehme, wird immer die Methode aus Klasse B ausgeführt).

Bin für jede Hilfe dankbar :rtfm:

 

[0x7F800000]

Ich vermisse irgendwie ein "extends"...
...und überlege mir schonmal, was du sonst noch etwas übersehen haben könntest ???:L

Also, wenn ich einfach so annehme, dass da lediglich das extends fehlt, erscheint mir da alles logisch...

Du hast es doch selbst gesagt:
B erweitert A
B kriegt die methode mit der signatur "void test(A)" einfach vererbt
B überschreibt NICHT die methode mit der Signatur "void test(A)", sondern erstellt eine neue mit der Signatur "void test(B)"

ref1 ist vom Typ A deklariert und vom typ B definiert, ordnet also signaturen wie folgt methoden zu:

ref1{
  "void test(A)" -> die methode aus A
  "void test(B)" -> die methode aus B
}

wenn du versuchst, diesen code auszuführen:

ref1.test(ref2);

dann schaut sich der compiler das an, stellt fest dass da nur die Signatur "void test(A)" angebracht ist, fragt dynamisch, was das objekt ref1 an methoden mit der Signatur "void test(A)" zu bieten hat, und das ist natürlich die ganz normale methode aus A...


_______________
Hättest du das überschrieben, also:

class B extends A{
  @Override
  public void test(A a){
    Sys...out..blah("B");
  }
}

dann würde ref1 natürlich folgende methoden den signaturen zuordnen:

ref1{
  "void test(A)" -> die methode aus B, die aus A wurde ja dadurch überschrieben
}

und beim aufruf

ref1.test(ref2);

würde da auch "B" rauskommen...

Okay so?:bahnhof:

 

[hdi]

dann schaut sich der compiler das an, stellt fest dass da nur die Signatur "void test(A)" angebracht ist, fragt dynamisch, was das objekt ref1 an methoden mit der Signatur "void test(A)" zu bieten hat, und das ist natürlich die ganz normale methode aus A...

Das ist nicht ganz korrekt finde ich. Er sucht erstmal in der Klasse A nach einer Methode mit der Singatur: void test(B), und findet eine solche Methode nicht.
Allerdings kann er über "Reference Widening" ein B zu einem A casten, wie du schon richtig geahnt hast. (Weil B IS-A A)
Und das macht er dann auch.

Warum aber ruft er nicht die Methode void(B) der Klasse B auf, immerhin passt das ja von dem Parameter her viel genauer (sogar exakt)?
Antwort: Der Compiler kennt nicht den wahren Typ einer Variablen:

A a = new B();

für den Compiler ist das "a" eine Referenz auf ein A, NICHT auf ein B.
Das Reference Widening übernimmt auch die JVM, nich der Compiler. Die JVM sagt dem Compiler einfach: Jaja, passt schon, kannste aufrufen.
Der Compiler weiss aber noch immer nicht, dass das ein B ist, oder ein X, oder sonst was. Er glaubt der JVM einfach.

Deshalb durchscht er die Klasse B gar nicht erst. Er weiss nicht mal, dass es diese Klasse gibt!

Soweit sollte das nachvollziehbar sein. Die Frage ist, warum ruft er die Version von B auf, falls man die Methode aus A überscheibt.
Hier mischt sich wieder die JVM ein: Sie sagt dem Compiler, dass es eine andere Methode gibt, die genau die selben Parameter erwartet.
In diesem Fall wird die Methode der Klasse aufgerufen, von dem der Typ WIRKLICH ist.

Zusammenfassung: Es geht nicht darum, welche Methode am ehesten zutrifft von den Parametern. Es geht darum, welche Methode genau der Klasse, die der Compiler sieht (A), am ehesten zutrifft. Und das ist eben (A a) durch Reference Widening.
Erst wenn Methoden EXAKT gleich sind, also überschrieben, wählt er die passendere aller verfügbaren aus den Klassen, indem die JVM ihm sagt von welchem Typ das Objetk jetzt wirklich ist.

Die JVM ist sozusagen der Gehilfe bei der Methoden-Auswahl. Entweder man kann die Methode, die der Compiler wählen würde (immer die des Typs der Variablen), irgendwie casten, dann bestätigt das die JVM.
Oder es gibt wirklich gleiche MEthoden, dann übernimmt die JVM eine Korrektur der Auswahl und reicht es an den Compiler zurück.

Anm: Dieses Gerede von wegen "die JVM sagt dem Compiler" usw kann man nicht wörtlich nehmen, und ist sicher nicht "korrekt". Zur Laufzeit gibt es den Compiler gar nicht. Aber zumindest von der Logik her funktioniert es so wie beschrieben, glaube und hoffe ich zumindest

 

[trunkz0r]

whoops, genau das extends bei klasse B hab ich vergessen

also so weit hab ich das ja alles verstanden, aber das erklärt nicht wieso bei
ref1.test(ref2);

die methode aus A ausgeführt wird. die methode aus B würde ja ebenfalls von den parametern passen, wär sogar etwas spezifischer.

was auch noch anzumerken ist, ist dass wenn ich statt
A ref1 = new B()

das so schreib
B ref1 = new B()

dann wird auch tatsächlich die methode aus B aufgerufen.

edit: das habe ich vor dem oberen post geschrieben

 

[hdi]

lies nochmal meinen Post, ich hab den editiert.

 

[faetzminator]

natürlich erklärt es das.
wenn du ein Objekt A hast, hast du (nebst den Object Methoden) folgende zur Verfügung:
- void test(A)
Wenn du ein Objekt B hast, hast du grundsätzlich
- void test(B)
aber natürlich auch noch
- void test(A) aus A

nun, dein ref1 ist ein A und hat damit alle Methoden von sich und seiner Superklasse(n), sicher nicht aber der Subklasse(n). Das ist, als würdest du fragen, warum Object keine print() Methode hat, die von ihm geerbte Klasse Stream kann das ja....

Gruss, faetzminator

 

[Landei]

Was du willst könnte vielleicht so gehen (ungetestet):

[highlight=Java]public class A<X extends A<X>>{
public void test(X x){
System.out.println("Methode in A wurde aufgerufen");
}
}
[/highlight]
[highlight=Java]public class B extends A<B>{
public void test(B b){
System.out.println("Methode in B wurde aufgerufen");
}
}
[/highlight]

 

[hdi]

nun, dein ref1 ist ein A und hat damit alle Methoden von sich und seiner Superklasse(n), sicher nicht aber der Subklasse(n).

Das stimmt nur halb. Das ref1 ist ein B, nur für den Compiler ist es ein A. Wie gesagt, sobald du die Methode überschreibst, wird die Version von B aufgerufen.
Wäre mal interessant zu wissen wie genau das funzt, meine Erklärung vorhin war schon extrem wischiwaschi. (wenn auch vom Verhalten her richtig)