toSring()-Methode

[sk72]

Hallo,

kann mir einer genauer erklären, was die toString-Methode macht, sobald ich sie überschreibe?

Ist es so, dass es den Objekten der Klasse den Rückgabewert der toString()-Methode als "Namen" gibt, wie das folgende Bsp. zeigt:

public class Test 
{
	private int x;
	private int y;
	
	public Test(int x, int y)
	{
		this.x = x;
		this.y = y;
	}
		
	public static void main(String[] args)
	{
		Test t = new Test(5,8);
		System.out.println(t);				// Test
	}
	
	@Override
	public String toString()
	{
		return "Test";
	}
	
}

 

[Clayn]

Sie wird einfach aufgerufen wenn quasi eine String Beschreibung eines Objekts nötig ist wie zum Beispiel bei System.out.println().

Was allerdings die Beschreibung ist, ist dir überlassen. Das kann einfach nur der Name der Klasse sein oder wie bei java.awt.Color z.B. noch zusätzlich die Farbwerte.

Allerdings sollte die Beschreibung einigermaßen sinnvollsein.

Bei deinem Beispiel würde jedes Objekt der Klasse Test immer beim ausgeben "Test" anzeigen.
Da wäre zum Beispiel noch eine einbeziehung von x und y sinnvoll da dies die Objekte unterscheidet

 

[nillehammer]

Die toString-Methode ist gedacht, um eine String-Repräsentation eines Objekts zu erhalten. Der String enthält wünschenswerterweise informative Daten. In der undüberschriebenen Standardimplementierung sieht man nur eine Objekt-Id. In der überschriebenen Variante würde man dort den Wert von Instanzvariablen unterbringen. In Deinem konkreten Beispiel also bspw so:

@Override
public final String toString() {
 return new StringBuilder("Test:").append("x=").append(this.x)
   .append(",y=").append(this.y).toString();
}

So kann man für debugging-Zwecke bspw. durch Aufruf der toString-Methode den Status eines Objekts loggen oder mit System.out.println anzeigen.

 

[sk72]

Check!

Vielen Dank

 

[Landei]

@Override
public final String toString() {
 return new StringBuilder("Test:").append("x=").append(this.x)
   .append(",y=").append(this.y).toString();
}

Is nich dein Ernst, oder? Das ist das reinste Cargo Cult Programming: Das mit dem [c]StringBuilder[/c] bekommt der Compiler bei so einfachen Konstellationen selbst hin (in einer Schleife wäre das was anderes), der einzige Effekt ist, dass deine Version dadurch unübersichtlich wird. Außerdem wird eine [c]toString[/c]-Methode typischerweise nicht zehn Millionen mal in einer engen Schleife aufgerufen - selbst wenn es so ein wenig schneller wäre, würde es nicht ins Gewicht fallen, also ein Fall von Premature Optimization.

Ich fände das am am hypschesten:

@Override
public final String toString() {
  return String.format("Test: x=%d, y=%d", x, y);
}

 

[hüteüberhüte]

[OT]

The term cargo cult, as an idiom, originally referred to aboriginal religions which grew up in the South Pacific after World War II. The practices of these groups centered on building elaborate mock-ups of airplanes and military landing strips in the hope of summoning the god-like airplanes that had brought marvelous cargo during the war.

[/OT]

Back on topic: Viele Methoden rufen auf einem übergeben Objekt toString() auf, um eine textuelle Beschreibung des Objekts zu erhalten. toString() ist eine Methode von Object und wird deshalb an alle Klassen vererbt. Sie sollte nach Möglichkeit den aktuellen Zustand des Objekts zurückgeben (Klassenname, Werte der Attribute usw.)

 

[Neomatrix433]

    @Override
    public String toString() {
	return "Test [x=" + x + ", y=" + y + "]";
    }

Bitte macht nicht solche Sachen wie String.format(..... oder gar irgendwelche Schleifenkonstrukte in der toString()!!!!

Die 3 Methoden die immer überschrieben werden sollten sind: hashCode(), equals(Object obj) und toString()-Methode!!

Was dann wie folgt aussehen sollte:

package de.berlin.matrix.blue.core;

public class Test {

    private int x;
    private int y;

    @Override
    public int hashCode() {
	final int prime = 31;
	int result = 1;
	result = prime * result + x;
	result = prime * result + y;
	return result;
    }

    @Override
    public boolean equals(Object obj) {
	if (this == obj)
	    return true;
	if (obj == null)
	    return false;
	if (getClass() != obj.getClass())
	    return false;
	Test other = (Test) obj;
	if (x != other.x)
	    return false;
	if (y != other.y)
	    return false;
	return true;
    }

    @Override
    public String toString() {
	return "Test [x=" + x + ", y=" + y + "]";
    }

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

    public static void main(String[] args) {
	Test t = new Test(5, 8);
	System.out.println(t); // Test
    }
}

Die Methode toString() liefert wie eben gesagt wurde eine für Menschen lesbare Repräsentation des Objektes auf ganz ganz simple weise hier wäre die Ausgabe: Test [x=5, y=8].
Wenn man die toString() nicht überschreibt bekommt man: de.berlin.matrix.blue.core.Test@464 (Das ist der fullqualifidname also packetname.Object getrennt durch @ und dann kommt die ID des erstellten Objektes.

Das ist beim Debuggen sehr schlecht wenn man wissen will wie das Objekt gerade aussieht. Daher immer die toString() so einfach wie möglich überschreiben. Eclipse liefert gleich eine Automatik um diese Methoden generieren zu lassen da es später wirklich zur Tiparbeit wird die Methoden zu schreiben ;-)

Die hashCode() liefert wie der Name schon sagt den HashCode eines Object dieser ist wichtig wenn ein Object serialisiert wird.
Und die equals(Object obj) ist zum vergleichen von Objekten.

Das überschreiben einer Methode wird immer über die Annotation @Override angegeben.

MFG

 

[Clayn]

EDIT: Ahh lesen soll helfen xD Sry

 

[Landei]

    @Override
    public String toString() {
	return "Test [x=" + x + ", y=" + y + "]";
    }

Bitte macht nicht solche Sachen wie String.format(..... oder gar irgendwelche Schleifenkonstrukte in der toString()!!!!

Was spricht gegen [c]String.format[/c]? Bei komplexeren Objekten wird alles andere schnell unübersichtlich.

Die 3 Methoden die immer überschrieben werden sollten sind: hashCode(), equals(Object obj) und toString()-Methode!!

Nicht immer, sondern wenn es sinnvoll ist. [c]toString[/c] ist fast immer sinnvoll. [c]equals[/c] ist für bestimmte veränderliche Klassen bereits "richtig" (nämlich als ==) implementiert (man denke nur an Klassen, die einfach eine Funktion A->B abbilden, da ist ohne zusätzliche Informationen kein anderer vernünftiger Vergleich möglich). [c]hashCode[/c] braucht man nur dann zu überschreiben, wenn es irgendwie sinnvoll ist, das Objekt als Schlüssel einer [c]HashMap[/c] zu verwenden, was nicht immer der Fall ist. Und wenn man versehentlich veränderliche Felder bei der Berechnung mit einbezieht, ist das Chaos schon programmiert...

 

[Spacerat]

    @Override
    public String toString() {
	return "Test [x=" + x + ", y=" + y + "]";
    }

Bitte macht nicht solche Sachen wie String.format(..... oder gar irgendwelche Schleifenkonstrukte in der toString()!!!!

Die 3 Methoden die immer überschrieben werden sollten sind: hashCode(), equals(Object obj) und toString()-Methode!!

Was dann wie folgt aussehen sollte:

//...siehe original Post...

Die Methode toString() liefert wie eben gesagt wurde eine für Menschen lesbare Repräsentation des Objektes auf ganz ganz simple weise hier wäre die Ausgabe: Test [x=5, y=8].
Wenn man die toString() nicht überschreibt bekommt man: de.berlin.matrix.blue.core.Test@464 (Das ist der fullqualifidname also packetname.Object getrennt durch @ und dann kommt die ID des erstellten Objektes.

Das ist beim Debuggen sehr schlecht wenn man wissen will wie das Objekt gerade aussieht. Daher immer die toString() so einfach wie möglich überschreiben. Eclipse liefert gleich eine Automatik um diese Methoden generieren zu lassen da es später wirklich zur Tiparbeit wird die Methoden zu schreiben ;-)

Die hashCode() liefert wie der Name schon sagt den HashCode eines Object dieser ist wichtig wenn ein Object serialisiert wird.
Und die equals(Object obj) ist zum vergleichen von Objekten.

Das überschreiben einer Methode wird immer über die Annotation @Override angegeben.

MFG

Gut gelernt... weiter machen. Sag bescheid, wenn's Zeit ist diese Aussage zu revidieren.
Nein, im Ernst. Landei's Version hat schon was. Ein einziges Stringliteral, zwei Variablen und übersichtlich, besser geht's nicht. Warum sollte man so etwas nicht in "toString()" verwenden? Die Mängel an "hashCode()" spar ich mir aber "equals()" muss noch dran glauben (apropos Glauben... ich kann's kaum glauben, so etwas im Anfänger-Forum als Tip lesen zu müssen):

class SomeClass {
  // hashCode ist passend überschrieben...

  @Override
  public boolean equals(Object obj) {
    if(this == obj) {
      return true; // kurz und buendig, identische Objekte sind inhaltlich gleich!
    }
    if(obj instanceof SomeClass) {
      SomeClass sc = (SomeClass) obj;
      // vergleichen
      return ergebnis;
    }
    return false;
  }
}

[EDIT]Im übrigen... das man "equals()" und "hashCode()" nicht notwendigerweise überschreiben muss, hat Landei ja bereits erwähnt. Und wenn man eine davon überschreibt, sollte man auch die andere überschreiben.[/EDIT]

 

[bygones]

    @Override
    public String toString() {
	return "Test [x=" + x + ", y=" + y + "]";
    }

Bitte macht nicht solche Sachen wie String.format(..... oder gar irgendwelche Schleifenkonstrukte in der toString()!!!!

nette Ausrufezeichen - unterstreicht natuerlich ein Argument ohne Beweis.

und allein die equals methode von Eclipse zeigt dass es bei weitem nicht schoen und intuitiv ist...

 

[Neomatrix433]

Ja ich würde an dieser stelle einfach mal sagen danke an die die mich bis auf das kleinste berichtigt haben. Da kann ich dann nichts mehr hinzufügen.

Es geht mit der Automatik von Eclipse einfach schneller und Zeit ist Geld wenn es einem dann nicht so passt kann man die Methoden eh noch anpassen. Und es sind letztlich alles Sachen die zum Programmierstil gehören (String.format.... oder schleife in der toString()) und den sollte man wenn man im Team arbeitet absprechen. Hab ihr hier im Forum CODE-CONVENTION, Code-Syleguidelines angegeben an die man sich hier halten muss?? Dann hab ich die überlesen ;-) [EDIT]Im übrigen... das man "equals()" und "hashCode()" nicht notwendigerweise überschreiben muss, hat Landei ja bereits erwähnt. Und wenn man eine davon überschreibt, sollte man auch die andere überschreiben.[/EDIT] Exakt richtig dann weiter machen bitte.
Und ja ich hab es so gelernt an der Uni was soll ich machen wenn einem das so beigebracht wird Asche auf mein Haupt

Sorry für die !!!!!! und das nicht exakte Formulieren.

 

[hüteüberhüte]

Die 3 Methoden die immer überschrieben werden sollten sind: hashCode(), equals(Object obj) und toString()-Methode!!

Entschuldigung, aber das ist doch Bockmist. hashCode und equals stehen in gar keinem Bezug zu toString. Wenn Objekte nicht miteinander verglichen werden sollen oder aus ihnen kein Hashwert generiert werden soll, macht es keinen Sinn, diese Methoden auch zu überschreiben

Das klingt so à la ich hab da mal was gelesen bezüglich aller möglichen Methoden aus Object, die möglicherweise auch überschreiben werden könnten

 

[Neomatrix433]

Entschuldigung, aber das ist doch Bockmist. hashCode und equals stehen in gar keinem Bezug zu toString. Wenn Objekte nicht miteinander verglichen werden sollen oder aus ihnen kein Hashwert generiert werden soll, macht es keinen Sinn, diese Methoden auch zu überschreiben

Das klingt so à la ich hab da mal was gelesen bezüglich aller möglichen Methoden aus Object, die möglicherweise auch überschreiben werden könnten

Wat los hier??? Meinen Post nicht richtig gelesen ist doch jetzt klar das mit den Methoden wie oft muss man sich hier entschuldigen??? Wegen nicht exakter Ausdrucks- und Schreibweise!!!

 

[hüteüberhüte]

Sry, war ein bisschen langsam mit dem Eintippen Da inzwischen alles geklärt zu seien scheint, ignoriere meinen Kommentar einfach