Schlüsselworte this (nicht this();)

[Kel]

Soweit ich das verstanden habe, benötigt man die this-Referenz für 2 Sachen:

1: Man übergibt in einer Methode (und/oder Konstruktor) Parameter (lokale Variablen), die gleich heissen wie eine Instanzvariable

public class Foo {
    privat int x;
}

public class Bar extends Foo {
  public Foo(int x) {
      this.x = x;
  }
}

Dient nur dazu, dass man die Instanzvariable und die lokalen Variablen unterscheiden kann, da sie gleich heissen.

this.x

ist Objektvariable.x und

x

ist die lokale Variable.


2: Man ruft in einem Konstruktor einen überladenen Konstruktor in der gleichen Klasse auf (z.B. um Standardwerte beim Erzeugen eines Objektes festzulegen)
Hier ist Verwendung 1 + 2 zusammen

public class Foo {
   privat int x;
   privat int y;

   public Foo {
      this(2, 3)
   }

   public Foo (int x, int y) {
     this.x = x;
     this.y = y;
   }
}

Wenn man ein Objekt erzeugt, kriegt es ja alle Instanzvariablen und alle Methoden von der Klasse mitgegeben, also ist jeder Aufruf vom Objekt auf eine Methode auf das Objekt bezogen, wozu braucht man dann noch

this

innerhalb einer Methode?
Es muss ja einen Grund geben, wieso man dauernd

this.x = x

schreibt, auch ohne die beiden Fälle.
Wenn jemand ein einfaches Beispiel hätte, wäre ich sehr dankbar, ich bin mir nämlich ziemlich sicher, dass ich was sehr wichtiges bei

this

übersehen habe :rtfm:.

 

[thorstenthor]

Konstruktoren werden nicht überladen. Das ist von der Begrifflichkeit her falsch.

this referenziert die als Instanz vorhandene umgebende Klasse.

Aus einem Konstruktor müssen manchmal andere Konstruktoren aufgerufen werden, denen z.B. default-Werte übergeben werden. Gleichnamige Variablen hast du auch schon genannt. Manchmal möchte man dadurch auch etwas verdeutlichen (Lesbarkeit). Dann fällt mir noch synchronized auf dem eigenen Objekt zu dem Thema ein. Außerdem Klassen innerhalb von Klassen oder Methoden und Zugriffe auf "höhergelegene Objekte".

 

[Kel]

Konstruktoren werden nicht überladen. Das ist von der Begrifflichkeit her falsch.

"Java von Kopf bis Fuß", Seite 249

Sie können in einer Klasse mehrere Konstruktoren haben, wenn sich deren Argumentlisetn unterscheiden. Hat man in einer Klasse mehrere Konstruktoern, heißt das, dass man überladene Konstruktoren hat

this referenziert die als Instanz vorhandene umgebende Klasse.

Wie meinst du das genau?

Aus einem Konstruktor müssen manchmal andere Konstruktoren aufgerufen werden, denen z.B. default-Werte übergeben werden. Gleichnamige Variablen hast du auch schon genannt.

Das sind ja die beiden Sachen, die ich oben geschrieben hatte.

Manchmal möchte man dadurch auch etwas verdeutlichen (Lesbarkeit).

Okay.

Dann fällt mir noch synchronized auf dem eigenen Objekt zu dem Thema ein.

Sagt mir noch gar nichts, ist das etwas in Bezug auf Threads?

Außerdem Klassen innerhalb von Klassen oder Methoden und Zugriffe auf "höhergelegene Objekte".

Klassen innerhalb von Klassen?
Methoden und Zugriffe auf "höhergelegene Objekte"? Kann ich mir aktuell nichts drunter vorstellen.

 

[thorstenthor]

Außerdem auch noch in dem Fall, dass eine Referenz der eigenen Klasse einer Methode übergeben wird.

1. nebenläufige Programmierung und
2. innere Klassen nachgucken

---

Früh ist es.

 

[Kel]

Okay, die beiden Sachen kann ich morgen nachgucken, relevant sind sie für mein Wissensgebiet aber wohl noch nicht (stecke grade bei Polymorphie/Generalisierung und den Grundlagen der Objektorientierung soweit).

Ein einfaches, kurzes Beispiel auf meinem Wissensstand wäre nett. Etwas, wo ich sehen kann, dass man ohne

this

dort nicht auskommt und was mir den Sinn von

this

ausserhalb der beiden oben genannten Möglichkeiten liefert (abgesehen von denen, die du bereits aufgezählt hast, aber soweit bin ich halt noch nicht).

Trotzdem danke für deine Hilfe, ich schau mir deine Sachen mal an wenn ich ausgeschlafen hab .

 

[faetzminator]

Ein einfaches, kurzes Beispiel auf meinem Wissensstand wäre nett. Etwas, wo ich sehen kann, dass man ohne

this

dort nicht auskommt und was mir den Sinn von

this

ausserhalb der beiden oben genannten Möglichkeiten liefert (abgesehen von denen, die du bereits aufgezählt hast, aber soweit bin ich halt noch nicht).

Na, [c]this[/c] ist einfach unerlässlich. Ein Beispiel zu thorstenthor's Aussage (was nicht nur unbedingt innere Klassen und Nebenläufigkeit betrifft...):
Du würdest gerne Achterbahn fahren. Die [c]Bahn[/c] kennt dazu [c]addMensch(Mensch)[/c]. Jetzt könntest du einen neuen Menschen erzeugen, so z.B. [c]bahn.addMensch(new Mensch("Fritz"))[/c] oder einen bereits existierenden Menschen dadrauf schicken: [c]bahn.addMensch(hans)[/c]. Aber eigentlich willst ja du Achterbahn fahren, und nicht jmd anderes (bzw. wär dir das egal). darum rufst du nun [c]bahn.addMensch(this)[/c] auf.

 

[Andi_CH]

"Java von Kopf bis Fuß", Seite 249 ...

Hm hätte mich ja eigentlich auch interessiert, aber leider hat die elektronische Version keine Seitennummern :-(
Hilfst du uns noch mit der Kapitelnummer oder dem Titel weiter?

 

[Michael...]

Ein einfaches, kurzes Beispiel auf meinem Wissensstand wäre nett. Etwas, wo ich sehen kann, dass man ohne

this

dort nicht auskommt und was mir den Sinn von

this

ausserhalb der beiden oben genannten Möglichkeiten liefert (abgesehen von denen, die du bereits aufgezählt hast, aber soweit bin ich halt noch nicht).

Ob man wirklich nicht ohne

this

auskommt, kann ich nicht sagen. Es gibt sicherlich viele Möglichkeiten ein

this

zu vermeiden. Das könnte aber zum einen unschön, zum anderen recht fehleranfällig werden.
In der "Anfängerprogrammierung" spielt

this

m.M. eine eher untergeordnete Rolle. Hierzu könnte man ein etwas künstliches Beispiel anführen: Eine Klasse möchte sich als MouseListener an sich selbst oder einer selbst erzeugten Komponente registrieren:

class TestKlasse extends JComponent implements MouseListener {
	public TestKlasse() {
		JPanel panel = new JPanel();
		...
		panel.addMouseListener(this);
		addMouseListener(this);
	}
	...	
}

Anwendung findet

this

z.B. auch beim Observer Pattern. Da hier der Observer (Beobachter) sein beobachtetes Objekt (Observable) gar nicht kennt. Übergibt das Observable (für den Fall der Fälle) bei einer Änderungsbenachrichtigung eine Referenz auf sich selbst mit.

Ähnlich ist es bei den Model - View Komponenten in Swing (JList, JTree, JComboBox, JTable...) hier registrieren sich die Komponenten als Listenern selbst an deren Models (ähnlich wie Beispiel oben).

 

[Kel]

Hilfst du uns noch mit der Kapitelnummer oder dem Titel weiter?

Gerne. Kapitel 9 - Leben und Sterben eines Objektes (S. 235), 14 Seiten nach dem Kapitelanfang ist das besagte Zitat.
"Kurzrückblick: Vier Dinge, die man sich zu Konstruktoren merken sollte", davon das "Ding" mit der Nummer 4.

@faetzminator: Das Beispiel verstehe ich noch nicht ganz, es gibt also eine Superklasse

Bahn

, welche die Methode

addMensch(Mensch name)

besitzt (und als Parameter ein Objekt vom Typ Mensch erwartet). Davon erbt die Unterklasse

Mensch

?
Oder andersrum,

Bahn

erbt von

Mensch

?
Weil irgendwo muss ja definiert sein, was ein

Mensch

-Objekt ist und man muss ja ein Objekt vom Typ

Mensch

erzeugen können.

@Michael...: Dein Beispiel kapier ich auch nicht, liegt aber daran dass ich mit GUI und Eventlistener noch nichts gemacht habe.

 

[Michael...]

@Michael...: Dein Beispiel kapier ich auch nicht, liegt aber daran dass ich mit GUI und Eventlistener noch nichts gemacht habe.

Gerade bei solchen Sachen, bei denen es um Assoziationen zwischen einzelnen Objekten geht, wird das

this

relevant.
Also weiter Lernen, dann wird Dir die Notwendigkeit von this schon bewusst ;-)

 

[SlaterB]

'überladen' halte ich übrigens für einen passenden Begriff, was spricht dagegen?
findet man bei google oftmals, unter anderem

Galileo Computing :: Java ist auch eine Insel – 5.5 Objekte anlegen und zerstören
5.5.3 Parametrisierte und überladene Konstruktoren

 

[thorstenthor]

1. Konstruktor aus Konstruktor heraus aufrufen
2. Zugriff auf eigene Attribute, z.B. bei gleichnamigen Variablen
3. Zugriff auf eigene Attribute aus inneren Klassen heraus
4. Übergeben der eigenen Referenz an eine Methode
5. synchronized-Block auf dem eigenen Objekt
6. Lesbarkeit /evtl. Konvention

Das sind doch wenigsten schon mal ein paar Punkte.

Ich erahne schon, wie der Kenntnisstand ungefähr ist, aber die Existenz des this würde ich nicht anzweifeln; es gibt Merkwürdigeres.