This-Referenz als Returnwert einer Methode?

[OOPler]

Ich verstehe nicht warum man Methoden, wenn sie einen this-Referenz als Rückgabewert besitzen, verketten kann. Dazu folgendes Bspl:

public class Bruch
{
   private int zaehler;
   private int nenner;

  public void print()
  {
   System.out.println(zaehler + "/" +nenner);
  }
  
  public Bruch setzeWerte(int zaehler, int nenner)
  {
	this.zaehler = zaehler;
	this.nenner = nenner;
	return this;
  }

  public Bruch multipliziere(int faktor)
  {
	setzeWerte(zaehler*faktor, nenner);
	return this;
  }

}

public class BruchTest
{
	public static void main(String[] args)
	{
		Bruch b1 = new Bruch();
		System.out.println("Wert des Bruches b1: ");
		b1.setzeWerte(1,2).print();
	}
}

Warum lassen sich nun die beiden Methoden verketten. This ist doch eine eine Referenz auf ein Objekt Bruch?Wieso lassen sich nun beide Methoden verketten?

 

[Joose]

Warum lassen sich nun die beiden Methoden verketten. This ist doch eine eine Referenz auf ein Objekt Bruch?Wieso lassen sich nun beide Methoden verketten?

"b1" ist auch nur eine Referenz auf ein Objekt. Und von diesem Objekt kannst du auch Methoden aufrufen.
Korrekt, this ist die Referenz auf das "aktuelle" Objekt.
"return this;" gibt somit das Objekt selbst zurück und von diesem Objekt kannst du wieder Methoden aufrufen.

 

[OOPler]

Also gibt die Methode praktisch eine namenlose Referenz zurück, auf welche ich mit dem punktoperator wieder zugreife?

 

[Joose]

Genau du könntest den Rückgabewert von der Methode "setzeWert" in einer lokalen Variable zwischenspeichern.
Und mit dieser lokalen Variable weiterarbeiten oder eben wie oben -> direkt den Punkt"operator" verwenden.

Achtung: Solche Verkettungen sind aber nicht immer passend und sollten mit Vorsicht eingesetzt werden.
Nimm an du hast eine Verkettung von 10 Methodenaufrufen.
Es fliegt eine Exception -> Wie findest du jetz am Besten heraus, welcher der 10 Aufrufe genau die Exception warum verursacht hat und warum?

Außerdem sind solche "Verkettungen" je länger sie sind schwieriger zu lesen (Aufruf 1 gibt Objekt X zurück, Aufruf 2 gibt Objekt Y zurück usw.)

 

[OOPler]

Eine Frage stellt sich mir aber noch wenn return this das objekt selbst zurueck gibt, aber noh kein objekt, zur zeit als die methode geschrieben wurde angegt wurde. Dann wird im spaeteren verlauf ein objekt angelegt, hier b1. Also gibt return this praktisch b1 als Objekt zurueck?

 

[arilou]

Man muss bei Java etwas vorsichtig sein - es wird mitunter "schlampig gesprochen".

Wenn man's exakt nimmt, wird in Java niemals "ein Objekt übergeben" oder "ein Objekt zurückgegeben" oder ähnliches, sondern immer Objekt-Referenzen (volgo "Pointer"). Man kann auch kein "Objekt deklarieren", sondern nur eine Objekt-Referenz-Variable (eine Variable, die einen Pointer beinhaltet).

'this' ist genauso ein Pointer wie b1.
Und der '.'-Operator ist einfach die Pointer-Dereferenzierung.

 

[Flown]

Der Fachbegriff für solche Konstrukte nennt sich FluentAPI und StringBuffer ist so implementiert.

 

[OOPler]

Zeigt this auf b1 und hat diesen als rueckgabewert?

 

[Flown]

Nein this und b1 zeigen auf das selbe Objekt.

 

[OOPler]

This ist praktisch eine referenz nur halt keine referenzvariable?

 

[Flown]

This ist eine kontextabhängige Referenzvariable.

 

[arilou]

'this' ist eine Systemvariable, die nur gelesen werden kann, und immer eine Referenz auf das "umgebende Objekt" liefert, zu dem die aktuelle Ausführung (Methode) gehört.
Daher bekommt man z.B. in 'static' Methoden einen Fehler, wenn man auf 'this' zugreifen möchte - ist ja kein Objekt "drumrum".

 

[Thallius]

Im obigen Beispiel finde ich das übrigens ziemlich unangebracht. Das eine Methode die Werte in einem Objekt setzt eine Referenz auf das Objekt zurück gibt ist unerwartet und unüblich. Ich würde so etwas nicht implementieren da es mehr verwirrt als hilft.

Gruß

Claus

 

[Natac]

Findest du? Also gerade bei Settern sehe ich bei einigen APIs häufig ein "return this", eben damit man es als Fluent API nutzen kann.

Parent p = new Parent()
p.addChild(new Child().setA(42));

Finde ich persönlich auch gar nicht so doof, da es doch den Code irgendwie aufbläht, wenn man jedes Element nochmal kurz zwischenspeichern muss, um Setter aufzurufen. Ist aber vielleicht auch eine Geschmacksfrage.

Nachvollziehen, dass es trotzdem unsauber ist, kann ich allemal. Von Klassen mit solchen Settern erben wird dann auch lustig und unterstreicht deine Argumentation. Aber für "kleiner Klassen" finde ich es durchaus zu gebrauchen.