Tutorial equals und hashCode überschreiben

[neurox]

Hallo allerseits,

ich habe ein kleines Tutorial zum Thema equals und hashCode geschrieben:

http://blog.buhbuhbuh.de

Wer sich dafür interessiert, ist herzlich eingeladen mal vorbei zu schauen. Auch für konstruktive Kritik bin ich immer dankbar.

Viele Grüße
neurox

[SlaterB]

ich wäre froh, nie
if (xy) befehl;
oder
else befehl;
lesen zu müssen

Klammern, Klammern, Klammern, gerade für die Anfänger

----

zwei Produkte mit gleicher artikelNr, gleichem preis, aber unterschiedlicher produkteBezeichnung
würden bei dir equal sein, aber unterschiedlichen hashCode() liefert -> aua

falls produkteBezeichnung immer von artikelNr abhängig sein soll, (was du wohl kaum garantieren kannst), dann brauchst du es in der hashCode-Berechnung gar nicht

edit:
zudem: produkteBezeichnung != artikelBezeichnung

[neurox]

Zitat: SlaterB

	zwei Produkte mit gleicher artikelNr, gleichem preis, aber unterschiedlicher produkteBezeichnung würden bei dir equal sein, aber unterschiedlichen hashCode() liefert -> aua

In dem Fall hast Du wohl nicht genau gelesen. Ich habe davor ja extra geschrieben, dass ich das Objekt noch mal erweitert habe, damit man sieht, wie man aus einen String auch noch einen hashCode heraus bekommt und nicht nur aus int und BigDecimal. Aber vielleicht ist das auch etwas missverständlich.

Aber mit den Klammer hast Du schon recht. Ich werde das noch mal etwas überarbeiten. Dann stehen da zwar etwas mehr Zeilen, aber vermutlich ist es dann noch leserlicher.

Grüße
neurox

[maki]

Hier meine Kritikpunkte:
Zwei BigDecimals mit == zu vergleichen ist eig. nicht korrekt (wie eig. bei allen Objekten)

Würde auch vermeiden, alles in einem if/else Block zu schreiben, Boch macht das in seinem Buch auch anders

[neurox]

Zitat: maki

	Hier meine Kritikpunkte: Zwei BigDecimals mit == zu vergleichen ist eig. nicht korrekt (wie eig. bei allen Objekten)

... das ist sogar ganz und gar nicht korrekt. Habe ich übersehen. Werde ich auch noch ändern.

Zitat: maki

	Würde auch vermeiden, alles in einem if/else Block zu schreiben, Boch macht das in seinem Buch auch anders

Ich sehe schon, das Buch ist beliebt

[maki]

Zitat:

	Ich sehe schon, das Buch ist beliebt

Ja, sehr, auch hier.
Stimme zwar nicht mit allem darin überein (wozu braucht jede serialisierbare Klaase eine UUID? Meist will man gar nicht zwischen verschiedenen Versionen serialisieren), würde es aber jedem Java Entwickler empfhelen, nicht nur den angehenden.

[faetzminator]

Zitat: SlaterB

	Klammern, Klammern, Klammern, gerade für die Anfänger

Hier haben wir aber ein unnötiges else case vorliegen.

1
2
3
4
5
if (a) {
    return b;
} else {
    return c;
}

finde ich leserlicher mit

1
2
3
4
if (a) {
    return b;
}
return c;

noch schöner fänd ich in diesem Beispiel einen check auf !instanceof und dann ein return false.

[neurox]

Zitat: maki

	Ja, sehr, auch hier. Stimme zwar nicht mit allem darin überein (wozu braucht jede serialisierbare Klaase eine UUID? Meist will man gar nicht zwischen verschiedenen Versionen serialisieren), würde es aber jedem Java Entwickler empfhelen, nicht nur den angehenden.

... oder weshalb man in gar keinen Fall Exemptions in der Geschäftslogik verwenden darf. Wir hatten das ja vor ein paar Tagen man am Beispiel von NumberFormatExceptions diskutiert. Er wäre ganz klar dagegen, allerdings habe ich da nirgends im Netz oder in der Java API eine besser Lösung gefunden.

Meint ihr, es macht Sinn solche Tuts hier einzustellen? Ich habe die mal (auch für mich selbst) geschrieben, weil ich immer wieder auf das Thema komme.

[neurox]

Soo, nun habe ich das ganze noch mal überarbeitet und eure Kommentare berücksichtigt.

Des weiteren habe ich den Code auch noch sehr ausführlich erklärt, so dass es nun auch einsteigertauglich sein sollte.

War ein bisschen Arbeit, ich hoffe es hilft dem einen oder anderen.

Grüße
neurox

[Spacerat]

Da musst du wohl noch mal bei:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@Override
public boolean equals(Object obj)
{
  if(this == obj) { // kurz und buendig
    return true;
  }
  if(!(obj instanceof Produkt)) {
    return false;
  }
  Produkt p = (Produkt) obj;
  // artikelNr ist primitiv und kann deswegen nicht null sein. Nullcheck eruebrigt sich.
  boolean rc = artikelNr != produkt.artikelNr;
  // equalsIgnoreCase missachtet inhaltliche Gleichheit und sollte deswegen nicht unbedingt verwendet werden.
  // Zustand von artikelBezeichnung und preis haengen von den Implementationen der Set-Methoden ab. Nullchecks erforderlich.
  rc &= artikelBezeichnung == produkt.artikelBezeichnung
            || (artikelBezeichnung != null && artikelBezeichnung.equals(produkt.artikelbezeichnung));
  rc &= preis == produkt.preis || (preis != null && preis.equals(produkt.preis);
  return rc;
}

[eRaaaa]

Zitat: Spacerat

	Da musst du wohl noch mal bei: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 @Override public boolean equals(Object obj) {   if(this == obj) { // kurz und buendig     return true;   }   if(!(obj instanceof Produkt)) {     return false;   }   Produkt p = (Produkt) obj;   // artikelNr ist primitiv und kann deswegen nicht null sein. Nullcheck eruebrigt sich.   boolean rc = artikelNr != produkt.artikelNr;   // equalsIgnoreCase missachtet inhaltliche Gleichheit und sollte deswegen nicht unbedingt verwendet werden.   // Zustand von artikelBezeichnung und preis haengen von den Implementationen der Set-Methoden ab. Nullchecks erforderlich.   rc &= artikelBezeichnung == produkt.artikelBezeichnung             || (artikelBezeichnung != null && artikelBezeichnung.equals(produkt.artikelbezeichnung));   rc &= preis == produkt.preis || (preis != null && preis.equals(produkt.preis);   return rc; }

du meinst wohl eher

1
2
//Produkt p ....
Produkt produkt = (Produkt) obj;

man könnte vllt auch noch

1
2
3
if (obj == null) {
            return false;
        }

vor die ganzen checks machen, die würde man sich dann nämlich sparen im falle von null - ich geh nu pennen, gn8 an alle

[Spacerat]

Zitat: eRaaaa

	du meinst wohl eher 1 2 //Produkt p .... Produkt produkt = (Produkt) obj;

Ja, mein ich.

Zitat: eRaaaa

	man könnte vllt auch noch 1 2 3 if (obj == null) {             return false;         } vor die ganzen checks machen, die würde man sich dann nämlich sparen im falle von null

...Hab' mir sagen lassen, dass das durch "instanceof" mit abgedeckt wird. An den nötigen Nullchecks der Instanzvariablen "artikelBezeichnung" und "preis" ändert das allerdings nichts.

[eRaaaa]

Zitat: Spacerat

	Hab' mir sagen lassen, dass das durch "instanceof" mit abgedeckt wird.

oh, stimmt ! dann nehm ich alles zurück (eclipse auto generate hauts auch rein )

nach der suche wie ich das umschreiben kann, bin ich auf folgenden beitrag gestoßen:

EclipseZone - Generate incorrect equals methods with ...

verwirrt mich jetzt irgendwie wie macht mans denn nu richtig
gerade auch weil er ja auch das buch anspricht, von dem hier die rede ist.

nu geh ich aber wirklich ins bett, hoffe dass mich bis zu mnachmittag jemand belehrt

[The_S]

Wenn du magst, kannst du ja auch mal hier einen Blick rein werfen :

Java Blog Buch : 04.03.11 Besondere Methoden (equals, hashCode und toString)

Außerdem werden (habs mal grob überflogen) die produktBezeichungen nicht verglichen (equals wäre hier angebracht) und die preise falsch (du machst das mit ==, bei einem BigDecimal verwendet man aber compareTo).

Nachtrag: OK, produktBezeichnung wird nicht verglichen, weil du ja die artikelNummer vergleichst. Sorry, hab ich überlesen.

[mvitz]

Für das vergleichen der Attribute kann man, wenn man faul ist auch: org.apache.commons.lang.builder (Commons Lang 2.4 API) benutzen.

Weiterhin würde mich jetzt auch nochmal interessieren, was nun beim checken der "Objektart" das richtige ist.

Bisher habe ich das immer wie in "Effective Java" gemacht:

1
2
3
4
5
6
7
8
9
10
11
public class A {
  public boolean equals(Object obj) {
    if (obj == this) {
      return true;
    }
    if (!(obj instanceof A)) {
      return false
    }
    A other = (A) obj;
    ...
}

[The_S]

Richtig ist alles, was den equals-contract erfüllt

Object (Java 2 Platform SE v1.4.2)#equals

Nachtrag: Da ist wohl was mit dem Link schiefgegangen.

[byte]

Am effektivsten gehts imo so: Building equals(), hashCode(), compareTo() and toString() with ease | Benjamin Winterberg

[SlaterB]

hashCode muss wirklich nicht alle Attribute beinhalten,
von beispielsweise
private String firstName;
private String lastName;
private Date birthday;
private String street;
private String city;
private String zipcode;
sollte firstName + lastName eindeutig genug sein, im Extremfall noch das Datum,
durch den Rest wirds auch nicht besser

[byte]

Lass die Datenbestände geeignet groß werden und Du hast unrecht.

[Marco13]

Im Gegenteil: Der Sinn von hashCode ist ja auch, dass er schnell ausgerechnet werden kann. Wenn man sich bei der Berechnung auf Fields beschränken kann, die immutable sind, kann es sogar Sinn machen, eine "private int hashCode" anzulegen, die schon im Konstruktor berechnet wird - und bei Personen sollte das eigentlich der Fall sein ... man ändert seinen Namen nicht 10 mal am Tag, und das Geburtsdatum ändert sich höchstens 4 mal

EDIT: @byte: hashCode muss nicht eindeutig sein, und ist es meistens auch nicht. Auch ein public int hashCode() { return 0; } wäre "richtig". Blöd, aber richtig.