Frage zu this und get.

[siebeck]

Habe folgendes Problem:

class Person {
String name;
int geburtsdatum;

void drucken() {
System.out.println("Name: "+name);
System.out.println("Geburtsdatum: "+geburtsdatum);
}

Person(String n, int gd) {
(*) name=n;
geburtsdatum=gd;
System.out.println("Person: "+this.name);
}
}

Offensichtlich ist es egal ob ich bei * this.name=n oder name=n schreibt.
Meine Frage dann, wozu hat this sonst eine Bedeutung, wenn es hier überflüssig ist?

2.Frage:
Im Buch steht noch folgendes:
public String getName() {return name;}

Ist diese Methode dazu da, wenn von außerhalb auf den Namen zugegriffen werden soll? In der Klasse wurde der name durch name=n bereits zugewiesen und mit System.out.println ausgegeben.

 

[Lim_Dul]

this hat den Vorteil, dass man explizit darauf hinweist, dass es sich um eine Membervariable handelt. Ist praktisch, wenn man keinen Editor mit Syntaxhighlighting hat, der einem das sowieso anzeigen.

Es gibt aber auch Fälle, wo this zwingend notwendig ist:

public class Foo {
  private String bar;

  public Foo(String bar) {
    this.bar = bar;
  }
}

Um hier im Konstruktor zwischen dem übergebenen Parameter und der Membervariablen zu unterscheiden, braucht man this. Allerdings sollte man solche Konstrukte weitesgehend vermeiden, also dass this wirklich nötig ist.

Zur get-Methode.

Richtig, in der Klasse wurde der Wert bereits zugewiesen.
Nur möchte man meistens nicht, dass die Klasse wie ein Schwarzes Loch alle Informationen einsackt, aber nichts wieder herausgibt. Von außerhalb möchte man gerne manchmal wissen, wie der Name der Person ist. Dafür ist diese Methode da.

 

[padde479]

class Person {
    String name;    // Name der Person
    int    bday;    // Geburtsdatum der Person

    void drucken() {
        System.out.println("Name: " + name);
        System.out.println("Geburtsdatum: " + bday);
    }

    public Person(String name, int bday) {
        this.name = name;
        this.bday = bday;
    }

Das Schlüsselwort this ist dazu da, um ein Objekt der eigenen Klasse zu beschreiben.

Offensichtlich ist es egal ob ich bei * this.name=n oder name=n schreibt.

Das stimmt soweit, da bei Dir der Übergabeparameter nicht mit dem Objekt der Klasse Person übereinstimmt. Wie Du aber an meinem Beispiel sehen kannst, bekommt der Konstruktor auch einen Parameter name. Wenn man jetzt mit dem Schlüsselwort this arbeitet, wird der Parameter dem Objekt der Klasse zugeordnet.

 

[foobar]

this wird dazu verwendet um zwischen gleichnamogen Variablen und Membern zu unterscheiden:

Person(String n, int gd) 
{
this.name=name;
geburtsdatum=gd;
System.out.println("Person: "+this.name);
}

Hier wird der Member name durch den Parameter name verdeckt., daher muß man ein this davor stellen um dem Member den Wert des Parameters zuzuweisen.

Mit this kann man ausserdem von einer inneren Klasse auf die äußere Klasse zugreifen:

public class Outer
{
   private String outer;

 ....
  private class Inner
 {
    public Inner()
   {
     System.out.println("outer " + Outer.this.outer);
   }
 }
}

 

[Der_Unwissende]

Hi,
wenn du ein this vor eine Instanzvariable schreibst, dann spricht man davon dass du diese Qualifizierst.
Du benötigst dieses this an vielen Stellen zwar nicht, aber es gehört zum guten Codestil. Schließlich verwendest du auch mehrere Zeilen für deine Java-Programm, du könntest es aber auch alles in eine schreiben.

Diese Qualifizierung sagt dir einfach, dass du dich gerade auf eine Instanzvariable beziehst. Hättest du zum Beispiel noch eine statische Variable, dann kannst du die nicht ohne weiteres als solche am Namen erkennen. Ausserdem kannst du die somit von lokalen Variablen unterscheiden:

int x;
int y;

public void doFoo(int x) {

  int y = this.y // ohne this könntest du nicht auf das y der klasse zugreifen

  y--;
  this.x = y * x; // und nochmal
}

Was getter und setter angeht, so Kapseln sie einfach den Zugriff auf Variablen. Variablen solltest du immer möglichst privat lassen. Ein direkter Zugriff ist nie nötig. Wenn du Methoden wie getX() und setX(... x) verwendest, kannst du in diesen Methoden sehr leicht von einer Variable abstrahieren. Zudem kannst du für das Setzen und Lesen der Variablen unterschiedliche Sichtbarkeiten zu lassen. Sind deine Variablen privat und du schreibst nur eine getX(), so wäre die eine Möglichkeit eine Variable nur lesbar zu machen.
Bei den Settern kannst du leicht die Gültigkeit prüfen. Sagen wir du hast ein byte, dass etwas in Prozent speichert. Würdest du nun -105 deiner Variable zu weisen, wäre ein gültiges byte, aber nicht unbedingt ein für dich sinnvoller Wert.
Auch bei den gettern hast du noch weitere Vorteile. Hast du z.B. eine Abhängigkeit, kann diese leicht aktuell berechnet werden. Sagen wir du hast eine Mehrwertsteuer und einen Bruttobetrag, dann kannst du den Betrag der Mehrwersteuer entweder immer dann berechnen, wenn der Bruttobetrag verändert wird und den in einer eigenen Variable speichern (sehr umständlich) oder du berechnest ihn halt im dazu gehörigen Get. Hier rechnest du erst den Wert aus und gibst ihn dann zurück.

Gruß Der Unwissende

PS Schlechte Beispiele im Buch. Mann sollte sich auch im eigenen Programm an das halten was man sagt!

 

[Leroy42]

aber es gehört zum guten Codestil.

Wer behauptet denn sowas?

Hast du schon mal ein Programm gesehen, in dem dieser gute Codestil
konsequent eingehalten wird?

Grauenhaft! :autsch:

 

[Der_Unwissende]

aber es gehört zum guten Codestil.

Wer behauptet denn sowas?

Unter anderem Allan Vermeulen in "The Elements of Java Style". Natürlich gibt es auch noch die Tatsache, dass Eclipse die fehlende Qualifizierung als Warning ausgeben kann. Wäre es einfach nur Unsinn hätte sich keiner die Mühe gemacht dies aufzunehmen.

Hast du schon mal ein Programm gesehen, in dem dieser gute Codestil
konsequent eingehalten wird?

Mehrere, finde es auch wenig problematisch mit dem zu arbeiten. Ehrlich gesagt verstehe ich da nicht, was da so grauenhaft dran sein sollte? Ich meine ob da jetzt noch ein this mehr steht oder nicht... Klar, die Zeilen werden wieder so lang und es kostet ja auch vertvolle ms das this zu tippen, aber ich habe auch eine Menge dummer Fehler gesehen, wo das this weggelassen wurde und bei einer Erweiterung des Codes ein Argument mit (dummerweise) gleichen Namen in eine Methode kam. Nun ja, wenn jmd. zu blöd zu refactoren ist, ist das dumm. Aber ganz ehrlich, gleich ein this schützt wenigstens vor solchen Leuten.

 

[Leroy42]

Ich meine ob da jetzt noch ein this mehr steht oder nicht... Klar, die Zeilen werden wieder so lang und es kostet ja auch vertvolle ms das this zu tippen

Aus dieser hohlen Gasse wollte ich ja sowieso nicht kommen. Wenn's mir darum ginge,
könnte ich ja gleich die Abschaffung von gettern und settern propagieren und alle Instanzvariablen
public fordern, um Unmengen nutzlosen Codes einzusparen

Menge dummer Fehler gesehen, wo das this weggelassen wurde und bei einer Erweiterung des Codes ein Argument mit (dummerweise) gleichen Namen in eine Methode kam. Nun ja, wenn jmd. zu blöd zu refactoren ist, ist das dumm.

Wenn jemand zu blöd ist, eine Methode um ein Argument zu erweitern, ohne sich mal den Quelltext
dieser Methode anzutun, um zu erkennen, ob sein neuer Parameter da drin schon vorkommt,
ist entweder er zu blöd, oder der Autor der Methode, der eine 100-Zeilen-Methode verzapft hat.

Aber ganz ehrlich, gleich ein this schützt wenigstens vor solchen Leuten.

Naja, nicht vor solchen Leuten, sondern solche Leute; um genau zu sein

Auf der anderen Seite ist aber doch sowieso alles, das kein this. vorgesetzt bekommt
entweder ein Parameter oder eine lokale Variable (das nachzuschauen sollte niemanden überfordern) ,
oder ein Member der Klassenhierarchie (egal ob vererbt oder nicht) oder einer Implementation.


Was also bringen dann diese unnützen this. Vornamen;
ich rede nicht von den notwendigen.

Auf jeden Fall keinen Informationsgewinn.

 

[foobar]

Ich hab mal eine zeitlang bei jedem Methodenaufruf und bei jedem Member this davor geschrieben, aber irgendwann war mir das zu viel Tipperei.

 

[Lim_Dul]

Sinnvoll ist es höchestens um in längeren Methoden kenntlich zu machen, wenn man einer Membervariablen was zuweist.
Andererseits ist das aber häufig ein Zeichen von schlecht strukturiertem Code.

Und in Zeiten, wo eine IDE alles farblich hinterlegt hält sich der Informationsgewinn in Grenzen.

 

[SnooP]

ich tippe häufig this. - weil mir eclipse dann die entsprechenden methoden anzeigt und ich die simpel auswählen kann - gerade bei größeren klassen mit entsprechender vererbungstiefe fehlt mir häufig die übersicht, wie genau die methoden jetzt hießen

und die Zuweisung bei set-Methoden oder im Konstruktor im Stil: this.name = name; find ich sehr leserlich, weil man damit sofort versteht was gemeint ist - beide Parameter heißen gleich und sollen auch das gleiche sein...

 

[Leroy42]

ich tippe häufig this. - weil mir eclipse dann die entsprechenden methoden anzeigt und ich die simpel auswählen kann

Probier's mal ohne this. -- einfach nur mit CTRL-+

this.name = name; find ich sehr leserlich, weil man damit sofort versteht was gemeint ist - beide Parameter heißen gleich und sollen auch das gleiche sein...

Hier finde ich es auch hilfreich/notwendig um in der Javadoc der Methode dann den richtigen
Namen als Parameternaman sehen zu können.