Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Hallo,
ich frage mich , wann ich in einer Methode oder dem Konstruktor this verwende und wann nicht?? Hier ein Beispiel aus einem
Buch.
Java:
public class Punkt
{
public int x;
public int y;
public Punkt() {}
public Punkt(int n, int m) {x = n; y = m; }
public void verschieben(int dx, int dy)
{
x += dx;
y += dy;
}
}
Was für einen Unterschied macht es, wenn ich z.B. im Kontruktor schreibe:
public Punkt(int n, int m) {this.x = n; this.y =m}
oder analog in der verschiebe-Methode.
Vielen Danke,
Iago
Hier macht es nicht wirklich einen Unterschied. Der grobe Sinn wird klarer, wenn du die Konstruktor-Parameter genau so wie die Instanz-Variablen nennst:
Java:
class Test {
private int x;
private int y;
Test(int x, int y) {
x = x; //sieht zwar komisch aus, macht dafür aber kein Sinn
this.x = x; //"this.x" ist die instanz-variable, "x" die Methoden-Variable
this.y = y;
}
}
Hallo,
ich frage mich , wann ich in einer Methode oder dem Konstruktor this verwende und wann nicht?? Hier ein Beispiel aus einem
Buch.
Java:
public class Punkt
{
public int x;
public int y;
public Punkt() {}
public Punkt(int n, int m) {x = n; y = m; }
public void verschieben(int dx, int dy)
{
x += dx;
y += dy;
}
}
Was für einen Unterschied macht es, wenn ich z.B. im Kontruktor schreibe:
public Punkt(int n, int m) {this.x = n; this.y =m}
oder analog in der verschiebe-Methode.
Vielen Danke,
Iago
Das this zeigt einfach an, dass es sich bei dem folgenden Aufruf um das aktuelle Objekt handelt. Man kann ja bekanntlich auf alle aktuell zugreifbaren Objekte über Objektname.methode() bzw. Objektname.variable (wenn public) zugreifen. Das this ist halt ein Platzhalter für das aktuelle Objekt, sodass über this.methode() auch alle geerbten methoden etc. aufgerufen werden können, natürlich auch diejenigen, die du neu geschrieben hast. Das this funktioniert allerdings bei Statischen Objekten nicht. Kleines Beispiel
Java:
public class Testklasse{
public static int testInteger=0;
public void gebeIntegerzahlaus(){
System.out.println(this.testInteger);
}
}
Das ganze wird nicht funktionieren, da die variable testInteger eine Klassenvariable ist, und dementsprechend nicht zu dem aktuellen Objekt "this" gehört sondern über den Klassennamen aufzurufen ist. Möglich wäre in diesem Fall
Java:
System.out.println(Testklasse.testInteger);
Wobei auch in diesem Fall theoretisch das this vernachlässigt werden kann...
Tatsächlic wrid das sehr wohl funktionieren, jedoch wird es inner ide wohl ne warnung gebenw eil man this benutzt um auf static krams zuzugreifen.
Anderer fall von this
class Formular extends JFrame(){
public Formular(){
JButton closebutton = new JButton("Close");
closebutton.addActionListener(new ActionListener({
//unterschiedliche sachen mit this:
public void actionEvent(){
this.close();
close(),
Formular.this.close();
}
});
}
}
(achtung syntax nur grob korrect und methodenamen etwas anders evtl)
Das erste versucht im ActionLisener die Methode close aufzurufen, (welche hier nicht existiert)
Das zweite ruft close auf, dies kann etnweder im Formular sein, oder im Actionlistener.
Das dritte ruft close im Formular auf.
-> Mit dem this hier kann man zb eindeutig angeben das die aufzurufende Methode im ACtionlistener sein soll und nicht im Formular.
Sorry, wenn ich da Falsch lag, aber ich glaube ich hatte da mal einen Fehler, aber kann auch was anderes gewesen sein. Trotzdem ist die Variante unschön. Wobei das denke ich Definitionssache ist
... wobei man "Testklasse." (genau so wie "this." in den anderen Fällen) weglassen kann, wenn der Bezeichner im entsprechenden Namespace eindeutig ist (Was IMO so sein sollte, aber das ist glaub schon bekannt )
@Empire Phoenix : Was steht da in grossen, roten Buchstaben oben dran? -> Java-Tags benutzen bitte.
Wie oben schon beschrieben, kannst du mit this lokal verborgene Klassenattribute sichtbar machen. Das machst du z.B. wenn die Parameter deines Konstruktors genauso heissen, wie die zugehörigen Attribute deiner Klasse. This ist jedoch zu vermeiden, da es recht Laufzeitintensiv ist.
This hat aber noch eine andere Bewandnis. This ist einfach die Instanz auf sich selbst. Du kannst also mit this das aktuelle Objekt an andere Objekte übergeben. Ein Beispiel für ein solches Szenario wäre ein Observer. Nehmen wir an, deine Klasse will über Zustandsänderungen notifiziert werden. Dann muss deine Klasse sich registrieren, und dabei seine Referenz mitgeben. Dies kannst du dann einfach machen, indem du die this-Referenz verwendest.
ich kann die aussage leider theoretisch nicht belegen. Meine Aussage gründet auf rein praxisorientierten Erfahrungen. Soweit ich weiss, ist die Auflösung der This-Referenz ein Vorgang, bei der Refexion verwendet wird (ich weiss es aber nicht genau).
Sorry, das ist Quatsch. Auf welche Variable zugegriffen wird (ob nun mit oder ohne this) wird schon vom Compiler festgestellt, der ja auch meckert, wenn selbige nicht vorhanden ist. Deshalb muss zur Laufzeit dort überhaupt nichts dynamisch aufgelöst werden (es sei denn, man verwendet selbst Reflection).
Und wenn du dir bei solchen Sachen nicht wirklich sicher bist, solltest du keine Neulinge mit Schauermärchen erschrecken.
Sorry, das ist Quatsch. Auf welche Variable zugegriffen wird (ob nun mit oder ohne this) wird schon vom Compiler festgestellt, der ja auch meckert, wenn selbige nicht vorhanden ist. Deshalb muss zur Laufzeit dort überhaupt nichts dynamisch aufgelöst werden (es sei denn, man verwendet selbst Reflection).
Und wenn du dir bei solchen Sachen nicht wirklich sicher bist, solltest du keine Neulinge mit Schauermärchen erschrecken.
Das meckern schliesst ja ein Laufzeitverhalten nicht aus. Ich habe nur gesagt, man sollte es, falls notwendig vermeiden. Zur Laufzeit muss schon etwas geschehen, sonst würde der ganze this-Mechanismus ja nicht greifen. Woher soll ein Objekt zur Kompilierzeit seine Referenz denn feststellen? Die exsitiert ja noch gar nicht. Kann sein, das meine Begründung quatsch ist, deshalb habe ich sie auch entsprechend notiert. Aber deine ist mal mindestens genauso ein Quark.
Mir ists aber auch egal, man bewerte die Aussage die ich ursprünglich getätigt habe. Da ging es eigentlich um was anderes. Deswegen ist mir die Haarspalterei auch egal.
Das meckern schliesst ja ein Laufzeitverhalten nicht aus. Ich habe nur gesagt, man sollte es, falls notwendig vermeiden. Zur Laufzeit muss schon etwas geschehen, sonst würde der ganze this-Mechanismus ja nicht greifen. Woher soll ein Objekt zur Kompilierzeit seine Referenz denn feststellen? Die exsitiert ja noch gar nicht. Kann sein, das meine Begründung quatsch ist, deshalb habe ich sie auch entsprechend notiert. Aber deine ist mal mindestens genauso ein Quark.
Mir ists aber auch egal, man bewerte die Aussage die ich ursprünglich getätigt habe. Da ging es eigentlich um was anderes. Deswegen ist mir die Haarspalterei auch egal.
Fühl dich doch nicht gleich angemacht. Das schlimmste, was passieren kann, ist doch dass du was lernst. Programmierung ist so komplex, da kann keiner alles wissen. Richtig gute Programmierer sind für sowas immer dankbar.
Programmierkonstrukte, wie Packages, Gültigkeitsbereiche, also Sichtbarkeiten, Klassen, etc. sind alles nur für den Programmierer gedacht, dass er sein Programm besser strukturieren kann. Der JIT-Compiler für die JVM, bzw. in C/C++ der Compiler, der das dann in Maschinencode übersetzt, optimiert den Code ja so, dass die Zugriffe minimiert werden, sowas wie Sichtbarkeiten sind für den vollkommen irrelevant, wenn sie vorher syntaktisch geprüft wurden. Klassen sind dann einfach Speicheradressen, usw. Eine this-Referenz-Variable wird dann einfach direkt durch die Speicheradresse repräsentiert.
