Frage zu HashCode Methode in Java

[Maik.Neumann]

Hallo !

Sehe ich das eigentlich richtig, dass die HashCode Methode in Java quasi für mehrere Objekte / Instanzen einer beliebigen Klasse identisch sein kann?

Also für einen Hashbasierten Container z.B. (wie die HashMap oder auch ein HashSet) stellt es quasi die Schublade / das Bulk dar, in dem mehrere Objekte / Instanzen einer Klasse abgelegt werden können?

Oder liefert hashcode für jedes Objekt / Instanzen einer Klasse immer unterschiedliche Werte zurück. In meinen bisherigen Testfällen habe ich immer unterschiedliche Werte von dieser Methode zurückgeliefert bekommen.

Danke und Gruß

 

[Joose]

Klar ist die

hashCode

Methode für alle Objekte/Instanzen einer Klasse gleich ... der Wert den du zurück bekommst kann, muss aber nicht gleich sein! Das hängt von der Implementierung der Methode ab.

Du kannst diese Methode überschreiben und selbst implementieren was zurückgegeben wird.
Ob du nun einen "komplizierten", möglicherweise einzigartigen Wert ausrechnest oder einfach stupide "-1" zurück gibst ist egal!

 

[Maik.Neumann]

Ich verstehe deine Aussage nicht: "lar ist die hashCode Methode für alle Objekte/Instanzen einer Klasse gleich"

Mein folgender Code liefert mir dieses hier zurück:

Bier bier1 = new Bier("Astra", "Hamburg", 34f);
System.out.println(bier1);
Bier bier2 = new Bier("Flens", "Flensburg", 34f);
System.out.println(bier2);
Bier bier3 = new Bier("Becks", "Bremen", 34f);
System.out.println(bier3);

Ergebnis:

Bier@785bda13
Bier@564a5320
Bier@29978622

Das ist die Standardimplementierung von Java und es wurde nichts von mir überschrieben

 

[Schesam]

Es sind ja auch verschiedene Objekte --> Verschiedener Hash. Erzeuge mal 2 "Bier"-Objekte mit den gleichen Parametern, da sollte der gleiche Hash rauskommen

 

[kaoZ]

Beim HashSet ist es aber so implementiert das ein Objekt welches als identisch identifiziert wird nicht hinzugefügt wird, sprich ,

kommt hierbei folgendes heraus :

import java.util.HashSet;

public class HashTest {
    
    static HashSet<Bier> set = new HashSet<>();

    class Bier{
        
        private String name;
        
        public Bier(String name) {
        
            this.name = name;
        }

        public String getName()     {return this.name;}

        @Override
        public boolean equals(Object o){
            return this.hashCode() == o.hashCode();
        }
        
        @Override
        public int hashCode(){
            return -1;
        }
    }

    public static void main(String[] args) {
        
        Bier eins = new HashTest().new Bier("Budweiser");
        Bier zwei = new HashTest().new Bier("Budweiser");
        
        System.out.println(eins.equals(zwei));
        
        System.out.println(eins.hashCode());
        System.out.println(zwei.hashCode());
        
        System.out.println(HashTest.set.add(eins)); //true
        System.out.println(HashTest.set.add(zwei)); //false
        
    }
}

true
-1
-1
true
false

Wie du sehen kannst werden hier beide Objekte wirklich als identisch behandelt, und dementsprechend auch das 2te nicht in das HashSet per add() hinzugefügt.

man sollte bei eigens designten Objekte eh immer

equals(Object o)

und

hashCode()

überschreiben, alleine schon da du sonst auf die Standardimplementierung zurückgreifen musst welche bei equals(Object o) z.B nur ein einfacher Referenzvergleich ist, der niemals gleich sein kann, schlussfolgernd daraus auch nicht der gleiche Speicherbereich alloziert wird und hashCode() niemals den gleichen Wert liefern kann ! auch nicht wenn beide Objekte (inhaltlich) identisch sind !

überschreibe ich z.B die Methoden nicht ergibt sich folgende Ausgabe bei gleicher Ausführung :

false
366712642
1829164700
true
true

objekte werden per equals() verglichen , der Referenzvergleich der Klasse Object liefert false, hashCode liefert die jeweilige textuelle Darstellung des allozierten Speicherbereiches ( Heap ) ,
die Objekte sind somit nicht Identisch, und werden beide dem HashSet hinzugefügt.

Immer daran denken , gleich != Identisch,

auch hier gern nochmal das Beispiel anhand von Zwillingen, nur weil Sie gleich aussehen ist es trotzdem nicht ein und die selbe Person

Falls noch unklarheiten da sein sollten immer raus damit

 

[Natac]

Also erstmal sollte man den hash mit

hashCode()

abfragen. Ein

toString()

funktioniert nur so lange, wie es eben von der Subklasse nicht überschrieben ist, was es aber prinzipiell sein sollte um bei Debug-Ausgaben sinnvolle Texte zu erhalten.

Prinzipiell dient ein Hash ja dazu Objekte "vorzusortieren". Objekte mit gleichem Hash kommen in die gleichen "Schubladen". Innerhalb dieser Schubladen wird mit

equals()

dann das Objekt rausgesucht, was du wirklich haben willst (so arbeiten auch HashMap und HashSet).

Das geht natürlich umso schneller, je weniger Objekte sich eine Schublade teilen (gute Hashfunktion). Sind viele Objekte in einer Schublade, so dauert dies entsprechend lange und der Nutzen des Hash-Werts geht verloren (schlechte Hashfunktion).

Und das verschiedene Objekte den selben Hash haben MÜSSEN, kannst du dir schon daran überlegen, dass es mehr String-Instanzen gibt, als mögliche Hashwerte.

So haben folgende Strings alle den selben Hash-Wert (1952508096) :

AaAaAa
AaAaBB
AaBBAa
AaBBBB
BBAaAa
BBAaBB
BBBBAa
BBBBBB

(Beispiel ist von stackoverflow)


@kaoZ: Dir ist bewusst, dass durch

public int hashCode(){return -1;}

public boolean equals(Object o){
  return o.hashCode() == hashCode();
}

Bei dir ALLE Bier-Instanzen als zueinander gleich angesehen werden!? Finde das Beispiel unglücklich gewählt, da du damit gar nicht mehr zwischen Gleichheit und hash unterscheidest. Ich gebe dir Recht, dass man equals und hashCode auf jeden Fall überschreiben sollte. Aber in deinem Fall hätte ich doch lieber den namen des Bieres genommen:

public int hashCode(){return name.hashCode();}
public boolean equals(Object o){
  if(o == null)return false;
  if(o == this)return true;
  if(o.getClass() == getClass()){return name.equals(((Bier)o).name);
  return false;
}

 

[kaoZ]

@kaoZ: Dir ist bewusst, dass durch

Ja ist es , es war nur ein sinnbildliches Beispiel..... damit war nicht gemeint das er die Methode so überschreiben soll...

Prinzipiell ging es nur darum das der TO erkennt das es sich in seinem Beispiel um verschiedene Objekte handelt, welche dadurch das diese nicht als identisch angesehen werden , trotzdem dem Set hinzugefügt werden, auch wenn Sie für ihn Optisch identisch erscheinen mögen.

[EDIT]Es war heute morgen schon recht früh ^^ mag sein das es nicht die sinnvollste Implementierung zu Anschauungszwecken war [/EDIT]

 

[kaoZ]

Hier nochmal ein interessanter Artikel dazu :

Angelika Langer - Effective Java