Vergleiche mit Equals(), hashCode() und ==

[rene_kochan]

Hallo Leute!
Ich bin etwas verwirrt, was die Vergleiche mit equals, hashCode() und == anbelangt. Es geht mir hierbei, um das theoretische Verständnis. Angenommen werden soll, dass Equals und HashCode() selbstverständlich überschrieben werden, damit der Vergleich auch richtig funktioniert. Ich will hier nur mal wissen, ob meine Überlegungen richtig sind oder was ihr zu den einzelnen Fällen zu sagen habt.
Hier mal meine Überlegungen dazu:
1. wenn Vergleich mit == true ergibt, kann Vergleich mit HashCode() true oder false ergeben
2. wenn Vergleich mit == false ergibt, kann Vergleich mit HashCode() true opder false ergeben
3. wenn Vergleich mit HashCode() true ergibt, kann Vergleich mit Equals() true oder false sein
4. wenn Vergleich mit HashCode() false ergibt, kann Vergleich mit == true oder false sein

Ich hoffe, ihr könnt mir da ein wenig helfen und mir sagen, ob meine 4 Überlegungen der Wahrheit entsprechen oder ob ich da einen Fehler habe.

Danke im Voraus für Eure Antworten!!!

 

[maki]

1. Nein, dasselbe Objekt hat immer denselben Hashcode, der darf sich auch nicht nachträglich ändern, sehr wichtig bei HashSet und HashMap, Hash...
2. Ja, Hashcode muss nicht eindeutig sein, wäre aber besser (effizenter)
3. Ja, wie gesagt, Hashcode ist nicht eindeutig
4. Nein, siehe Punkt 1

Ich vermisse equals in deiner Aufzählung, denn hashcode und equals gehören zusammen!

 

[SlaterB]

falls man hashCode() so baut, dass es eine Zufallszahl zurückgibt oder equals() zufällig zu true oder false ausgewertet wird,
so sind alle deine Aussagen richtig,

ansonsten musst du das näher begründen,
warum sollte z.B. bei == true, also bei ein und demselben Objekt der hashCode-Vergleich false ergeben können?

 

[rene_kochan]

Hallo!
Danke erstmal für die Antwort. Ich habe bei den Überlegungen natürlich nur die aufgezählt, bei denen ich mir noch nicht hundertprozentig sicher war. Der Grund für die Beschäftigung mit dieser Materie ist die SCJP - Prüfung, die ich noch ablegen will. Da kommen dann auch solche Fragen, wo man dann halt wissen muss, wenn == true ergibt, wie es dann bei Hashcode() und Equals() aussieht. Objekte vergleiche ich nur mit Equals und Hashcode und überschreibe diese Methoden freilich entsprechend.
Deshalb nochmals vielen Dank für die Antwort. Jetzt sehe ich da noch besser durch.
Tschau!

 

[Murray]

1. Nein, dasselbe Objekt hat immer denselben Hashcode, der darf sich auch nicht nachträglich ändern, sehr wichtig bei HashSet und HashMap, Hash...

Das stimmt so nicht ganz - der Hashcode darf (und sollte) sich ändern, wenn sich irgendwelche Attribute ändern, die in der equals-Methode berücksichtigt werden.

 

[0x7F800000]

Das stimmt so nicht ganz - der Hashcode darf (und sollte) sich ändern, wenn sich irgendwelche Attribute ändern, die in der equals-Methode berücksichtigt werden.

hast du nicht zufälligerweise zuhause einen Quanten-PC herumstehen, in dem ein und dasselbe objekt mehrere zustände gleichzeitig annehmen kann?

edit: okay, für die fragestellung ist die bemerkung zwar ohne bedeutung, aber es stimmt schon, sry, blödes Kommentar

 

[maki]

1. Nein, dasselbe Objekt hat immer denselben Hashcode, der darf sich auch nicht nachträglich ändern, sehr wichtig bei HashSet und HashMap, Hash...

Das stimmt so nicht ganz - der Hashcode darf (und sollte) sich ändern, wenn sich irgendwelche Attribute ändern, die in der equals-Methode berücksichtigt werden.

Wenn das Objekt in eine HashMap eingefügt wurde und sich danach der Wert von hashcode() ändert, bekommt man es nicht mehr aus der HashMap mit get().

 

[Murray]

hast du nicht zufälligerweise zuhause einen Quanten-PC herumstehen, in dem ein und dasselbe objekt mehrere zustände gleichzeitig annehmen kann?

edit: okay, für die fragestellung ist die bemerkung zwar ohne bedeutung, aber es stimmt schon, sry, blödes Kommentar

Was genau willst Du mir damit jetzt sagen?

 

[Murray]

Wenn das Objekt in eine HashMap eingefügt wurde und sich danach der Wert von hashcode() ändert, bekommt man es nicht mehr aus der HashMap mit get().

Das stimmt so nicht - wenn sich der Hashcode eines Values in einer HashMap ändert, kratzt das niemanden. Ändert sich dagegen der Hashcode des beim Einfügen verwendeten Key-Objektes, dann kann man mit diesem Key-Objekt das ursprünglich eingefügte Objekt mit get nicht mehr herausbekommen - das spricht aber erstmal nicht gegen den HashCode-Contract, sondern lediglich dagegen, veränderliche Objekte (mutables) als Keys zu verwenden.

 

[SlaterB]

aha, aber für alle Objekte, deren hashCode() man nie benutzt, soll sich dieser aber bitte ändern (können) oder wie?
sehr sinnvolle Unterscheidung

 

[maki]

aha, aber für alle Objekte, deren hashCode() man nie benutzt, soll sich diese aber bitte ändern (können) oder wie?
sehr sinnvolle Unterscheidung

Grundlegende Unterscheidung zwischen sog "Value Object" und "Entities".

Value Objects werden durch ihre Attribute eindeutig, zwei Value Objects mitdenselben Werten sollten austauschbar sein, und immutable. equals() und hashcode() beziehen sich dann auf die Attribute.

Entities werden durch ihre id eindeutig, sollten auch nicht mutable sein, equals() und hashcode() beziehen sich dabei auf ein id Attribut.
Problem: Nicht gespeicherte Entities haben keine ID, sind daher nicht unterscheidbar und können nicht in Collections/Maps verwendet werden