im neuen Heft im Kasten auf S. 28 steht zum Thema hashCode
"unveränderlich: Der Hash-Wert darf sich nicht ändern, sonst findet man das Objekt nicht wieder."
Deshalb sei der Anfangsbuchstabe schlecht, weil es vorkommen könne, dass eine Person z.B. durch Heirat ihren Nachnamen ändert.
Das ist doch irgendwie völlig verkehrt: wenn ich ein Objekt irgendwo mit Hilfe des HashWerts gespeichert habe (als Key in einer HashMap, in einem HashSet) dann darf sich <b>das Objekt</b> nicht ändern. Der hashCode muss/soll sich sogar mitändern, wenn das Objekt seine "Identität" ändert!
Es ist also genau andersrum.
Wenn ich eine Person p in einem HashSet ablege, und dann ändere ich den Nachnamen der Person (mit p.setNachname), dann wird die "alte Referenz" nicht wiedergefunden (d.h. contains liefert false); weil sich bei korrekter Implementierung der HashWert in 99,9% aller Fälle auch ändert.
Selbst wenn der hashCode sich nicht ändern würde - das könnte ja zufällig sein -würde es immer noch am equals scheitern.
Genau so soll es sein...
"unveränderlich: Der Hash-Wert darf sich nicht ändern, sonst findet man das Objekt nicht wieder."
Deshalb sei der Anfangsbuchstabe schlecht, weil es vorkommen könne, dass eine Person z.B. durch Heirat ihren Nachnamen ändert.
Das ist doch irgendwie völlig verkehrt: wenn ich ein Objekt irgendwo mit Hilfe des HashWerts gespeichert habe (als Key in einer HashMap, in einem HashSet) dann darf sich <b>das Objekt</b> nicht ändern. Der hashCode muss/soll sich sogar mitändern, wenn das Objekt seine "Identität" ändert!
Es ist also genau andersrum.
Wenn ich eine Person p in einem HashSet ablege, und dann ändere ich den Nachnamen der Person (mit p.setNachname), dann wird die "alte Referenz" nicht wiedergefunden (d.h. contains liefert false); weil sich bei korrekter Implementierung der HashWert in 99,9% aller Fälle auch ändert.
Selbst wenn der hashCode sich nicht ändern würde - das könnte ja zufällig sein -würde es immer noch am equals scheitern.
Genau so soll es sein...
Comment