compareTo() und equals()

[Strim]

Hey

Wieso ist es eigentlich so wichtig, wenn man compareTo() implementiert, equals() auch zu implementieren?

MfG, Tim

 

[Gucky]

Ich halte es für nicht wichtig. In welchem Zusammenhang denn? .equals() vergleicht die beiden Strings und gibt bei Gleichheit true zurück. .compareTo() vergleicht die Strings auf Lexikografische Größenunterschiede und gibt einen int zurück.

 

[KSG9|sebastian]

Ist es nicht.

Ich vermute du meinst hashCode und equals.

Im Prinzip gilt: liefert a.equals(b) true dann muss a.hashCode() = b.hashCode() sein. Das ist vor allem relevant bei diversen Collections welche mit Hash arbeiten.

 

[Natac]

Es ist wichtig, bei der Implementierung des Interfaces Comparable auch equals() zu überschreiben.

compareTo()

gibt

0

zurück, wenn beide Objekte gleich sind. dann wäre es schon schön, wenn

equals()

dann auch

true

zurückliefern würde. Ansonsten wäre das reichlich inkonsistent :autsch: . Zudem ist es das erwartete Verhalten, wenn man Comparable implementiert.

Und ich gebe Sebastian in dem Punkt Recht, dass dann auch hashCode() implementiert werden sollte, da gleiche Objekte den gleichen hashCode haben sollten. Und dies ist durch die Standard-Implementierung von hashCode nicht gegeben.

Gucky, wie kommst du auf Strings!? Davon steht doch hier nirgends etwas!?

 

[kaoZ]

Hier hab ich grad noch gefunden :

Aus diesem Grund macht es Sinn beim implementieren von Comparable , equals und hascode ebenfalls zu überschreiben :


[TIPP](Wenn compareTo() bei zwei gleichen Objekten 0 ergibt, so sollte equals() auch true liefern. Doch wird equals() nicht überschrieben, so führt die in Object implementierte Methode nur einen Referenzvergleich durch. Bei zwei im Prinzip gleichen Objekten würde die equals()-Standardimplementierung also false liefern. Bei hashCode() gilt das Gleiche: Zwei gleiche Objekte müssen auch den gleichen Hashwert haben. Ohne Überschreiben der Methode ist das jedoch nicht gegeben; nur zwei identische Objekte haben den gleichen Hashcode.))[/TIPP]

 

[Strim]

Danke für die Antworten.

Ich bin durch folgende Klausuraufgabe auf diese Frage gekommen:
Sie wollen Objekte der folgenden Klasse Task in der Queue ablegen. Die Klasse beschreibt
eine Aufgabe mit einer Priorität und einem Namen. Je höher der Prioritätswert
ist, desto höher ist die Priorität der Aufgabe. Aufgaben mit der höchsten Priorität sollen
zuerst aus der Queue ausgelesen werden. Ergänzen Sie dazu eventuell erforderliche
Methoden.

public class Task {
private int priority;
private String name;
}

Die Lösung ist hier auch:

public class Task implements Comparable<Task> {
private int priority;
private String name;
@Override
public boolean equals(Object other) {
// ohne Test auf identische Klasse
return priority == ( ( Task) other).priority;
}
@Override
public int compareTo(Task other) {
return other.priority - priority;
}
}

Hier hat der Prof nämlich auch equals() implementiert, was mich gewundert hat, da es ja nicht explizit gefragt ist. Aber ich denke er hat es, wie ihr auch sagt, einfach der Vollständigkeit halber und wegen der Konsistenz gemacht.

MfG,
Tim

 

[kaoZ]

naja explizit gefragt isses nicht , aber ich denke es dient vielleicht als hinweis darauf, das ja die noch benötigten methoden implementiert werden sollen , das schließt , insofern man jetzt davon ausgeht das sobald compareTo() implementiert wird, ebend auch equals() und hashcode() implementiert werden sollten, diese ebend mit ein .

🙂