equals() - hashCode() - Contract

[0x7F800000]

Reden wir hier immer noch von hashCode()? :autsch:

Naja, was soll man da eigentlich machen?
[highlight=Java]
import java.util.*;

public class _ {
private static class X{
private int x;
public X(int _){
x=_;
}
public void setX(int _){
x=_;
}
@Override
public boolean equals(Object other){
if(other instanceof X){
X y=(X)other;
return y.x==this.x;
}
return false;
}
@Override
public int hashCode(){
return x;
}
@Override
public String toString(){
return ""+x;
}
}
public static void main(String... _) {

HashSet<X> set=new HashSet<X>();
X a=new X(1);
X b=new X(2);
set.add(a);
a.setX(2);
set.add(b);
System.out.println(set); // [2, 2] toller set, alles im A**** 🙁
}
}
[/highlight]
Was soll man tun, wenn die hash-funktion von werten abhängt, die dauernd verändert werden sollen? Ist es da nicht besser den Benutzer der klasse mit einer exception darauf hinzuweisen, dass diese Objekte für Hash-Strukturen einfach nicht gedacht sind? Für (im wesentlichen) immutable objekte ist alles klar, und was macht man eigentlich mit den veränderlichen? :bahnhof: Ich würde eigentlich normal hashCode implementieren, und dann diejenigen elemente, die verändert werden müssen, aus dem set rausholen, verändern, wieder hashen und einfügen.

 

[Ebenius]

UnsupportedOperationException sollte man nur benutzen, wenn Methoden einer API als optional gelten, die spezielle Implementierung diese optionale Methode aber nicht unterstützt. In einer hashCode()-Methode eine Exception zu werfen halte ich im allgemeinen für ein Verbrechen. 🙂

Date.hashCode() macht es doch richtig vor; das Objekt gibt einen hashCode des derzeitigen Status wieder. Wenn der sich ändert, ist der hashCode ebenfalls anders. Kein Problem. Achtung: Ich vergesse gern, dass java.util.Date nicht immutable ist; falls es noch jemandem so geht...

Das Objekt selbst sollte sich doch nicht dafür interessieren müssen, dass es niemand falsch verwendet. Ein sich änderndes Objekt hat nichts in einer HashMap / einem HashSet zu suchen während es sich verändert. Dafür ist der Nutzer der Klassen zuständig, nicht das Objekt. Genauso müsste beispielsweise der Comparator der die Objekte irgendwie vergleichen kann auch UnsupportedOperationException schmeißen, weil ja irgendwer auf die Idee kommen könnte, die Objekte in einem TreeSet abzulegen. :autsch:

Ebenius

 

[SchonWiederFred]

Was soll man tun, wenn die hash-funktion von werten abhängt, die dauernd verändert werden sollen?

Dann muss der Benutzer verantwortungsbewusst mit der Klasse umgehen 🙂

Idealerweise verwendet man nur unveränderliche Objekte in HashSets bzw. als Keys in HashMaps. Wenn man von dieser Regel abweicht, muss man halt selber aufpassen.

 

[Stefan S.]

Gestern habe ich wieder angefangen mit kontextfreien Grammatiken rumzubasteln (disesmal in Java).
Da kommt durchschnittlich in jeder 10 Zeile irgendein "HashXyz" vor, das gesammte ding arbeitet bisher praktisch ausschließlich mit den Strukturen HashMap<T,HashSet<T>> (die eben eine Funktion darstellen, die Symbolen Mengen von anderen Symbolen zuordnen, sowas wie FIRST-sets oder so). Nur so als Beispiel... :bahnhof:

Du bastelst in deiner Freizeit freiwillig an CFG/Parsern? Sauber, man hat ja sonst nichts zu tun. :toll:

 

[Marco13]

Jaja, Student müßte man wieder sein :reflect: