this Keyword in Java

[MoxMorris]

Hallo!
Ich verstehe nicht, worauf sich this in unter stehendem Code bezieht. Könnte mir jemand das erklären, bitte? Debugging hilft nicht, es schreibt einfach, dass this = B ist. Also ich kann vermuten, dass this ein Instanz von Subklasse B ist, aber ich verstehe die Zuweisung von Werten an this nicht. Warum wird es zuerst null und dann "Otto of type B".

class A { //subclass
    private String stringRepr;

    A(String s) {
        stringRepr = s + " of type A";
        System.out.println("I am " + this);
    }
   
    public String toString() {
        return stringRepr;
    }
}

public class B extends A { //superclass
    private String stringRepr;
   
    B(String s) {
        super(s);
        stringRepr = s + " of type B";
        System.out.println("I am " + this);
    }

    public String toString() {
        return stringRepr;
    }

    public static void main(String[] arg) {
        System.out.println("instantiate B");
        B b = new B("Otto");
    }
}

Output:

instantiate B
I am null
I am Otto of type B

Danke im Voraus!

 

[Robert Zenz]

Deine Kommentare sind verkehrt herum, super ist die Klasse von der geerbt wird, sub ist die die erbt. Und hier ist eine allgemeine Erklaerung zum Thema this.

Wenn du dir dazu schreibst was und wo ausgegeben wird, wird dir das schnell klar:

class A { //superclass
    private String stringRepr;

    A(String s) {
        stringRepr = s + " of type A";
        System.out.println("A: I am " + this);
    }
   
    public String toString() {
        return stringRepr;
    }
}

public class B extends A { //subclass
    private String stringRepr;
   
    B(String s) {
        super(s);
        stringRepr = s + " of type B";
        System.out.println("B: I am " + this);
    }

    public String toString() {
        return stringRepr;
    }

    public static void main(String[] arg) {
        System.out.println("instantiate B");
        B b = new B("Otto");
    }
}

instantiate B
A: I am null
B: I am Otto of type B

Um das noch weiter auszubauen, muessen wir wissen welche Methoden tatsaechlich aufgerufen werden:

class A { //superclass
    private String stringRepr;

    A(String s) {
        stringRepr = s + " of type A";
        System.out.println("A: I am " + this);
    }
   
    public String toString() {
        System.out.println("A: toString()");
        return stringRepr;
    }
}

public class B extends A { //subclass
    private String stringRepr;
   
    B(String s) {
        super(s);
        stringRepr = s + " of type B";
        System.out.println("B: I am " + this);
    }

    public String toString() {
        System.out.println("B: toString()");
        return stringRepr;
    }

    public static void main(String[] arg) {
        System.out.println("instantiate B");
        B b = new B("Otto");
    }
}

instantiate B
B: toString()
A: I am null
B: toString()
B: I am Otto of type B

Wir sehen also, dir fehlt eine Annotation welche dir beim Verstaendnis auch helfen wuerde:

class A { //superclass
    private String stringRepr;

    A(String s) {
        stringRepr = s + " of type A";
        System.out.println("A: I am " + this);
    }
   
    public String toString() {
        System.out.println("A: toString()");
        return stringRepr;
    }
}

public class B extends A { //subclass
    private String stringRepr;
   
    B(String s) {
        super(s);
        stringRepr = s + " of type B";
        System.out.println("B: I am " + this);
    }

    @Override
    public String toString() {
        System.out.println("B: toString()");
        return stringRepr;
    }

    public static void main(String[] arg) {
        System.out.println("instantiate B");
        B b = new B("Otto");
    }
}

Also this bezieht sich immer auf die aktuelle Instanz, auch wenn Methoden aufgerufen werden in der super Klasse. Also im Konstruktor von A ist this eine Instanz von B, dadurch wird die toString Methode von B aufgerufen. Da der Konstruktor von A aber durchlaufen wird bevor du das Feld B.stringRepr setzt, kann die Methode B.toString keine Wert zurueckliefern, weil du bist einfach zu frueh.

 

[MoxMorris]

Deine Kommentare sind verkehrt herum, super ist die Klasse von der geerbt wird, sub ist die die erbt. Und hier ist eine allgemeine Erklaerung zum Thema this.

Wenn du dir dazu schreibst was und wo ausgegeben wird, wird dir das schnell klar:

class A { //superclass
    private String stringRepr;

    A(String s) {
        stringRepr = s + " of type A";
        System.out.println("A: I am " + this);
    }
  
    public String toString() {
        return stringRepr;
    }
}

public class B extends A { //subclass
    private String stringRepr;
  
    B(String s) {
        super(s);
        stringRepr = s + " of type B";
        System.out.println("B: I am " + this);
    }

    public String toString() {
        return stringRepr;
    }

    public static void main(String[] arg) {
        System.out.println("instantiate B");
        B b = new B("Otto");
    }
}

instantiate B
A: I am null
B: I am Otto of type B

Um das noch weiter auszubauen, muessen wir wissen welche Methoden tatsaechlich aufgerufen werden:

class A { //superclass
    private String stringRepr;

    A(String s) {
        stringRepr = s + " of type A";
        System.out.println("A: I am " + this);
    }
  
    public String toString() {
        System.out.println("A: toString()");
        return stringRepr;
    }
}

public class B extends A { //subclass
    private String stringRepr;
  
    B(String s) {
        super(s);
        stringRepr = s + " of type B";
        System.out.println("B: I am " + this);
    }

    public String toString() {
        System.out.println("B: toString()");
        return stringRepr;
    }

    public static void main(String[] arg) {
        System.out.println("instantiate B");
        B b = new B("Otto");
    }
}

instantiate B
B: toString()
A: I am null
B: toString()
B: I am Otto of type B

Wir sehen also, dir fehlt eine Annotation welche dir beim Verstaendnis auch helfen wuerde:

class A { //superclass
    private String stringRepr;

    A(String s) {
        stringRepr = s + " of type A";
        System.out.println("A: I am " + this);
    }
  
    public String toString() {
        System.out.println("A: toString()");
        return stringRepr;
    }
}

public class B extends A { //subclass
    private String stringRepr;
  
    B(String s) {
        super(s);
        stringRepr = s + " of type B";
        System.out.println("B: I am " + this);
    }

    @Override
    public String toString() {
        System.out.println("B: toString()");
        return stringRepr;
    }

    public static void main(String[] arg) {
        System.out.println("instantiate B");
        B b = new B("Otto");
    }
}

Also this bezieht sich immer auf die aktuelle Instanz, auch wenn Methoden aufgerufen werden in der super Klasse. Also im Konstruktor von A ist this eine Instanz von B, dadurch wird die toString Methode von B aufgerufen. Da der Konstruktor von A aber durchlaufen wird bevor du das Feld B.stringRepr setzt, kann die Methode B.toString keine Wert zurueckliefern, weil du bist einfach zu frueh.

danke für die Antwort! Eine Sache verstehe ich immer noch nicht, warum wird toString() Methode in Klassen A und B aufgerufen? Was ist der Grund dafür?

 

[temi]

Eine Sache verstehe ich immer noch nicht, warum wird toString() Methode in Klassen A und B aufgerufen? Was ist der Grund dafür?

System.out.println("B: I am " + this);

println() ruft intern toString() auf, wenn es this ausgibt.

 

[MoxMorris]

Wow, das wusste ich gar nicht 🤯
Gibt es noch was Änliches? Noch Kommandos, bei den Methoden mit bestimmten Namen aufgerufen werden, ohne den Aufruf selbst einzutippen?
Und danke!

 

[Robert Zenz]

So ziemlich immer wenn du + verwendest und es nicht um Zahlen geht. Das ist aber eine Compiler Sache, das passiert nicht zur Laufzeit sondern der Compiler aendert die Sachen (Syntactic Sugar).

String result = "Object: " + object;
String result = "Object: " + object.toString();

String result = 5 + "Some";
String result = Integer.toString(5) + "Some";

Oder was ich auch schon teilweise gesehen habe:

String result = 5 + "Some";
String result = new Stringbuilder().append(5).append("Some").toString();

Auto-Boxing funktioniert nach dem gleichen Prinzip (siehe auch meine Wiederholung dazu). Und wenn wir schon beim Thema sind, auch gleich die Wiederholung fuer Strings.

 

[Robert Zenz]

println() ruft intern toString() auf, wenn es this ausgibt.

Eigentlich ist es in dem Fall der Compiler, weil String-Konkatenierung. Bei println(this) ist es die Logik. Aber auf der anderen Seite enden wahrscheinlich alle Konkatenierungen als StringBuilder, also ist es eh wieder die Logik...aber halt im StringBuilder...oder im String.concat, das weisz ich nicht mehr.

 

[mrBrown]

So ziemlich immer wenn du + verwendest und es nicht um Zahlen geht. Das ist aber eine Compiler Sache, das passiert nicht zur Laufzeit sondern der Compiler aendert die Sachen (Syntactic Sugar).

String result = "Object: " + object;
String result = "Object: " + object.toString();

String result = 5 + "Some";
String result = Integer.toString(5) + "Some";

Oder was ich auch schon teilweise gesehen habe:

String result = 5 + "Some";
String result = new Stringbuilder().append(5).append("Some").toString();

Auto-Boxing funktioniert nach dem gleichen Prinzip (siehe auch meine Wiederholung dazu). Und wenn wir schon beim Thema sind, auch gleich die Wiederholung fuer Strings.

Nur als Ergänzung: Die StringBuilder-Variante dürfte es ab Java 5 bis 8 gewesen sein, ab 9 läuft das über invocedynamic, macht den Bytecode etwas kürzer und erlaubt theoretisch dann weitere Optimierungen zur Laufzeit. Für 99% der Entwickler dürfte das aber völlig irrelevant sein

 

[MoxMorris]

Ich habe noch eine interessante Frage.
Wenn Super- und Subklassen vorhanden sind, wird sich this auf die Subklasse beziehen. Aber was wird, wenn es 2 Subklassen und 1 Superklasse geben? Von welcher Subklasse spricht man dann? Ich habe es gerade probiert, eine neue Subklasse C erzeugt, aber this bezieht sich immer noch auf B Subklasse, obwohl die beide vollkommen gleich sind. Warum genau B Subklasse und nicht C?

 

[KonradN]

This weist ja immer auf eine genaue Instanz. Und die wurde von einer Klasse erzeugt. Du hast also irgendwo ein new KlassenName() oder so. Damit wird eine Instanz von KlassenName erzeugt und der Konstruktor zur Initialisierung aufgerufen. Dann verweist this natürlich auf diese Instanz.

Bei den Zugriffen auf diese Instanz spielt dann aber der Typ der Variablen eine Rolle. Denn da die Instanz in der Variable gespeichert wurde, ist das sowas wie eine minimale Anforderung. Bei this ist der Typ die umschließende Klasse. Wenn Du also im Konstruktor von Klasse A bist, dann ist klar, dass es mindestens A sein muss (oder eben eine abgeleitete Klasse).

Wenn Du also nun hast:

class A
class B extends A
class C extends A

Dann kannst Du per new B() eine Instanz von B erzeugen. Die Instanz hat dann den Typ a. Die this Variable in B weiss: Es muss vom Typ B sein oder abgeleitet. Die this Variable in A weiss: Es muss vom Typ A sein oder davon abgeleitet. In A kann es aber natürlich von B oder C sein. Das weiss man da nicht (aber man könnte es prüfen mit instanceof oder so).

 

[temi]

Wow, das wusste ich gar nicht 🤯
Gibt es noch was Änliches? Noch Kommandos, bei den Methoden mit bestimmten Namen aufgerufen werden, ohne den Aufruf selbst einzutippen?
Und danke!

Ja. Wenn du beispielsweise die Kollektion HashMap verwendest, dann verwendet diese intern die beiden Methoden equals() und hashCode(). Solange die HashMap mit Standardtypen verwendet wird (z. B. HashMap<String, String>) musst du nichts tun, weil String die beiden Methoden bereits passend überschreibt. Bei eigenen Klassen, die du mit HashMap verwendet möchtest, musst du selbst dafür sorgen, diese beiden Methoden passend zu überschreiben.

 

[mihe7]

Das geht jetzt zwar über das Thema hinaus, aber weil @temi die HashMap genannt hat, würde ich noch ergänzen, dass es neben solchen Nettigkeiten, die sich tatsächlich irgendwo im Code niederschlagen, auch Dinge gibt, die nur in der Spezifikation zu finden sind bzw. sich aus der Logik heraus ergeben (was ggf. auch daran liegt, dass sich nicht alles in der Sprache(!) Java ausdrücken lässt).

Beispielsweise wäre dies bei der besagten HashMap die Tatsache, dass der Schlüssel nicht verändert werden darf, man also am besten unveränderliche Objekte als Schlüssel verwendet. Da bin ich selbst schon drüber gestolpert

 

[Robert Zenz]

Beispielsweise wäre dies bei der besagten HashMap die Tatsache, dass der Schlüssel nicht verändert werden darf, man also am besten unveränderliche Objekte als Schlüssel verwendet. Da bin ich selbst schon drüber gestolpert

Gilt aber nur solange die Klasse equals/hashCode ueberschreibt, nicht?

 

[KonradN]

Gilt aber nur solange die Klasse equals/hashCode ueberschreibt, nicht?

Es darf sich der Schlüssel (also der Hashcode) nicht verändern. Wenn hashcode und equals nicht überschrieben wurden, dann ist der Hashcode konstant. Du kannst es aber auch überschreiben - aber der hashcode darf sich nicht mehr verändern.

Ist ja auch ganz klar - der hashcode wird verwendet, um das bucket, in dem ein Element landet, auszuwählen. Wenn sich der hashcode ändert dann wird ggf. in einem anderen bucket gesucht und daher das Element nicht gefunden.

Das ist aber alles nicht eine Automatik bei Java sondern einfach ein Verhalten der Klassen / Implementationen.

Automatisches Verhalten wie dieses Konvertieren in einen String wie es in 4.3.1

• The string concatenation operator + (§15.18.1), which, when given a String operand and a reference, will convert the reference to a String by invoking the toString method of the referenced object (using "null" if either the reference or the result of toString is a null reference), and then will produce a newly created String that is the concatenation of the two strings

und genauer / exakter in 5.1.11

5.1.11. String Conversion​

Any type may be converted to type String by string conversion.

A value x of primitive type T is first converted to a reference value as if by giving it as an argument to an appropriate class instance creation expression (§15.9):

• If T is boolean, then use new Boolean(x).
• If T is char, then use new Character(x).
• If T is byte, short, or int, then use new Integer(x).
• If T is long, then use new Long(x).
• If T is float, then use new Float(x).
• If T is double, then use new Double(x).

This reference value is then converted to type String by string conversion.

Now only reference values need to be considered:

• If the reference is null, it is converted to the string "null" (four ASCII characters n, u, l, l).
• Otherwise, the conversion is performed as if by an invocation of the toString method of the referenced object with no arguments; but if the result of invoking the toString method is null, then the string "null" is used instead.

beschrieben wurde, wäre aus meienr Sicht dann eher das ganze Kapitel 5 der JLS mit allen Umwandlungen:

Die String Umwandlung hatten wir schon, aber es gibt noch:

• widening / narrowing primitive conversions - die widening primitive conversions sind halt wichtig, wenn es z.B. zu Berechnungen kommt, denn die werden ja bei Berechnungen regelmäßig durchgeführt. (Also umwandlung zu einem int oder long um Berechnungen durchzuführen oder Umwandlungen zu double oder float. "Ich mache eine Berechnung mit chars - wieso kommt da ein int raus?" Neben den primitive Conversions in 5.1.x sind da dann auch die numeric contexts in 5.6 wichtig.
• Boxing / Unboxing

In einem etwas anderen Umfeld sind dann die Conversions bei Referenzen und Generic Types interessant. Da geht es aber halt weniger darum, dass da irgendwas gemacht wird sondern mehr darum, was erlaubt ist oder nicht. Findet sich natürlich auch im Kapitel 5 der JLS.

 

[mihe7]

Gilt aber nur solange die Klasse equals/hashCode ueberschreibt, nicht?

Was den zweiten Teil betrifft (zum ersten Teil hat @KonradN schon geschrieben): Das war eine Empfehlung ("best practise") und die gilt erstmal unabhängig davon. Natürlich kann man auch mit veränderlichen Objekten als Schlüssel in einer HashMap arbeiten, auch mit solchen, die hashCode aus Object nicht überschreiben - dann muss man allerdings schon sehr genau wissen, was man tut (Stichwort referentielle Gleichheit/Identität).