Methoden Verständnisfrage Vererbung von Methoden

[Werniman]

Hallo,
ich bin gerade dabei, das Buch "Schrödinger programmiert Java" durchzuarbeiten. Beim Thema Vererbung habe ich allerdings ein kleines Verständnisproblem.

Bisher hatte ich den Ablauf des Methodenaufruf in den früheren Beispielen so verstanden:
Oberklasse variable = new Unterklasse();
//erzeugt eine Referenzvariable vom Typ Oberklasse, die mit einem Objekt vom Typ Unterklasse verknüpft ist.

variable.methode();
// Es wird erstmal geschaut,ob es die Methode in der Oberklasse gibt und dann ob sie in der Unterklasse überschrieben wird (da das verknüpfte Objekt diesen Typ hat). Wenn die Methode aber bereits in der Oberklasse als static gekennzeichnet ist, wird gar nicht erst nach einer vererbten Methode gesucht.

Seh ich das so richtig ?

 

[White_Fox]

static heißt, daß es diesselbe Methode für alle Objekte dieser Klasse gibt. Ich würde sogar sagen, daß sie im eigentlichen Sinne gar nicht vererbt wird, da statische Elemente nicht mehr objektspezifisch, sondern allenfalls klassenspezifisch sind.

Ansonsten machst du dir meines Erachtens gerade zu viele Gedanken um Implementierungsdetails und es ist hilfreich, sich von diesen zu lösen. Eines der Geheimnisse in der objektorientierten Programmierung besteht in der Vereinfachung-und diese Vereinfachung muß man erstmal in sein Denken reinkriegen. (Das klingt zunächst trivial, ist tatsächlich aber alles andere als das.)

Eine Methode wird durch ihre Signatur, das ist die Kombination aus Rückgabewert, Methodenname und Aufrufparameter, definiert. Eigentlich legst du damit nur fest was du einem Objekt damit vor die Füße werfen kannst und was es daraufhin zurückliefert.

Was der Compiler im Hintergrund macht, ob er erst in der Oberklasse nach einer Methode sucht und dann in der Unterklasse schaut...ehrlich gesagt: das weiß ich gar nicht. Ich weiß nichtmal, ob man das so überhaupt sagen kann.
Was ich dir aber sagen kann: Gewöhne dir schnurstracks ab, in einer Hochsprache auf solche Ausführungsdetails zu schließen. Zwischen dem von dir geschriebenem Code und dem was der Computer dann tatsächlich macht liegen so viele Abstraktionsschichten und Optimierungsprozesse daß solche Überlegungen eigentlich immer fehl gehen.

 

[mrBrown]

Eine Methode wird durch ihre Signatur, das ist die Kombination aus Rückgabewert, Methodenname und Aufrufparameter, definiert.

Klitzekleine Korrektur am Rande: Signatur ist nur Name + Parameter

 

[temi]

Signatur ist nur Name + Parameter

Danke. Das war mir nicht bewusst.

 

[abc66]

Im Prinzip ist es ganz einfach. Es gibt Überladung, Überschreibung und Verstecken.
Zur Methodensignatur siehe hier: https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.2 (~= Name+Parameter)
Zur Vererbung siehe insbesondere den Abschnitt: Example 8.4.9-2. Overloading, Overriding, and Hiding

Ein Beispiel:

class A {
	float hidingExample1 = 1;

	static void hidingExample2() {
		System.out.println("hidingExample2 A " + new A().hidingExample1);
	}

	void overrideExample1() {
		System.out.println("overrideExample1 A " + hidingExample1);
	}

	void overloadExample1() {
		System.out.println("overloadExample1 A " + hidingExample1);
	}

	void overloadExample1(float f) {
		System.out.println("overloadExample1 A " + hidingExample1 + " " + f);
	}
}

class B extends A {
	float hidingExample1 = 2;

	static void hidingExample2() {
		System.out.println("hidingExample2 B " + new B().hidingExample1);
	}

	void overrideExample1() {
		System.out.println("overrideExample1 B " + hidingExample1);
	}
}

	public static void main(String[] args) {
		A a = new B();
		a.hidingExample2();
		B.hidingExample2();
		a.overrideExample1();
		a.overloadExample1();
		a.overloadExample1(3);
		new A().overrideExample1();
	}

Alles andere ist nicht erlaubt.
Frage: Was wird ausgegeben werden?

PS. a.hidingExample2(); sollte so nicht aufgerufen werden, hilft aber bei dem Verständnis.
PS2. Es ist zudem nicht erlaubt, die Sichtbarkeit von überschriebenen Methoden einzuschränken...

 

[abc66]

Wobei ich mir gerad unsicher bin, ob hidingExample2 nicht besser overrideAndHidingExample2 heißen müsste... Statische Methoden werden auch überschrieben, kommen jedoch bei der Polymorphie nicht zum Zuge.

 

[mrBrown]

Statische Methoden werden auch überschrieben

Werden sie das? Und werden Felder dann auch überschrieben?

 

[abc66]

Ich denke, man könnte auch von einer speziellen Form der Vererbung sprechen... Wenn du aber sagst, das ist Blödsinn, wirst du recht haben.

Jedenfalls darf man dessen/deren Sichtbarkeiten auch nicht einschränken.

 

[kneitzel]

Nunja - darüber bin ich auch etwas gestolpert und musste es doch gleich verifizieren: Es scheint zu stimmen.

Ich habe also einfach eine Klasse A mit statischer Methode test() gemacht. Dann Klasse B, die von A erbt.
==> B.test() war möglich und A.test() wurde ausgeführt.
Dann in b auch ein public static test() geschrieben und siehe da: Nun wurde diese Methode aufgerufen.

Hat mich etwas gewundert, denn ich meine, dass ich da in der Vergangenheit schon einmal drüber gestolpert bin und er so ein Konstrukt nicht mochte. Aber das kann auch an etwas anderem gelegen haben.

Nur zur Info: bei mir ging es um Builder in abgeleiteten Klassen. Ist evtl. der eine oder andere auch schon etwas drüber gestolpert

 

[mihe7]

Das ist einfach das Hiding statischer Methoden.

 

[mrBrown]

Ich habe also einfach eine Klasse A mit statischer Methode test() gemacht. Dann Klasse B, die von A erbt.
==> B.test() war möglich und A.test() wurde ausgeführt.
Dann in b auch ein public static test() geschrieben und siehe da: Nun wurde diese Methode aufgerufen.

B#test wird allerdings nur aufgerufen, wenn der statische Typ B ist. Dann ist A#test durch B#test versteckt, und B#test wird aufgerufen, sonst A#test.

Gleiches passiert ja, wenn test ein Feld und keine Methode wäre.

 

[kneitzel]

Das ist einfach das Hiding statischer Methoden.

Ja klar, ich erinnere mich jetzt nur nicht, wo die Problematik damals bei mir lag. Diese Thematik hat man in der Praxis ja in der Regel nicht wirklich. Zumindest erinnere ich mich jetzt nicht, wo diese Thematik jemals relevant gewesen wäre in meiner Praxis - abgesehen halt einmal bezüglich dieser abgeleiteten Builder. Daher halt tatsächlich eine gewisse Unsicherheit, wie es sich verhält. Und statt dies über JLS zu verifizieren ist ein kleiner Test halt schneller.

 

[mihe7]

Diese Thematik hat man in der Praxis ja in der Regel nicht wirklich.

Gott sei Dank

Vielleicht waren es statische Factory-Methoden bei abgeleiteten Klassen?

Und statt dies über JLS zu verifizieren ist ein kleiner Test halt schneller.

Wohl wahr - in der JLS ist es teilweise sehr schwierig, Sachverhalte herauszulesen (z. B. die Reihenfolge von Operatoren).

 

[kneitzel]

Vielleicht waren es statische Factory-Methoden bei abgeleiteten Klassen?

Die statische Methode war lediglich die getBuilder Methode (so dass es halt MyClass.getBuilder() ist statt eines neu MyClass.Builder() um den Builder zu bekommen. Wobei das Kernproblem bei abgeleiteten Buildern ja die Rückgabe des Builders ist. Man will ja den eigentlichen Builder behalten, auch wenn eine Methode vom Basis Builder aufgerufen wurde. Geht mit Generics relativ gut aber fand ich teilweise zumindest ungewohnt.

Generell sehe ich da sehr viel Code für wenig Aktivität. Da bin ich doch ernsthaft am überlegen z.B. Lombok einzuführen. Aber das muss man mal in einer ruhigen Minute im Team diskutieren ...

 

[M.L.]

Weiterhin kann man sich ein kleines Beispiel zwecks Studium ansehen und damit experimentieren: https://www.geeksforgeeks.org/inheritance-in-java/ (Single Inheritance)

  ... 
class one
{
    public static void print_geek()
    {
        System.out.println("Geeks");
    }
}
 
class two extends one
{
    @Override //Fehlermeldung: "method does not override or implement a method from a supertype" oder
//"print_geek() in two cannot override print_geek() in one"
//Lösung: static löschen

    public void print_geek()
    {
        System.out.println("for");
    }
}
...
two g = new two(); //Je nach instanziierter Klasse greift der Compiler auf die jeweils definierte Methode zu
        g.print_geek();
        //g.print_for();
        //g.print_geek();
...

Ansonsten könnte das Diamond-Problem aus der C++-Programmierung als (warnendes) Schlagwort dienen: https://www.geeksforgeeks.org/multiple-inheritance-in-c/