Überschreiben der equals-Methode

newbie-Frage hier:

So, in meinen Uni-Hausaufgaben muss ich das überschreiben der object-Klasse equals-Methode für eine neue Klasse von mir erstellt.

Die neue Klasse "Produkt" jedes Produkt hat ein Attribut "id" ist einzigartig. Also das ist, wie ich Overrided:

@Override
public boolean equals(Object obj) {
       final Product other = (Product) obj;
       if (id != other.id)
           return false;
       return true;
   }

Die Sache ist, dass dies zu tun ist 1,5 von 10 Punkten und es machte mich suspicius, einfach sein. So begann ich zu suchen und fand ich Dinge wie:

@Override
public boolean equals(Object obj) {
       if (this == obj)
           return true;
       if (obj == null)
           return false;
       if (getClass() != obj.getClass())
           return false;
       final Product other = (Product) obj;
       if (id != other.id)
           return false;
       return true;
   }

Die keinen Sinn ergeben für mich überhaupt, weil ich denke, dass die letzten wenn überprüfen Sie alle anderen ifs Einschränkungen. Was denken Sie?Was ist der bessere Weg, um diese Methode Überschreiben?

Dank!

Der Vertrag für gleich sagt, dass alle Objekte, die gleich sind, müssen den gleichen hashCode. Wenn Sie also überschreiben equals() überschreiben muss hashCode().

InformationsquelleAutor Iñaki | 2011-06-15

  1. 14

    Dem zweiten Stück code ist besser:

    • Es optimiert für x.equals(x), die nicht notwendig für Korrektheit, sondern ist eine hilfreiche Optimierung
    • Es bewältigt, mit x.equals(null) statt zu werfen NullPointerException
    • Es verarbeitet Objekte, die in einer ganz anderen Klasse, ohne daß eine ClassCastException was würde dir (z.B. x.equals("foo"))
    • Bedarf es der genaue gleichen Art, um eine symmetrische Beziehung; sonst obj.equals(x) könnte, ruft eine andere Methode, die zu einem anderen Ergebnis.
    Das zweite Stück code, das wird nicht funktionieren, wenn Sie eine Unterklasse Produkt ohne änderung der Semantik der Methode equals().
    Es hängt davon ab, was du damit meinst "arbeiten". Es wird nicht behandeln, eine Instanz von Produkt als gleich eine Instanz der Unterklasse, Nein - aber ich glaube nicht, dass das kaputt ist, ist es einfach ein Verhalten, das muss dokumentiert werden.
    ein.equals(b) immer false zurück wenn ein.getClass() == Product.class, b instanceof einige Unterklasse von Produkt -, und a und b haben die gleichen internen Zustand. So ist die equals () - Beziehung ist nicht symmetrisch. Dies verstößt gegen java.lang.Objekt-Vertrag.
    Es wird nur asymmetrisch sein, wenn b.equals(a) gibt true zurück,... und es wäre nicht, wenn es aufgerufen super.equals(a) was es sollte. Ohne dieser Prüfung a.equals(b) wird nur prüfen, für id so könnte es true " zurück, während b.equals(a) würde false zurückgeben, da a ist nicht eine Instanz der gleichen Unterklasse von Product oder eine Unterklasse der Unterklasse. Der Aufruf getClass() ist genau dort zu Hilfe Symmetrie.
    Wenn man eine abstrakte Klasse repräsentiert eine unveränderliche Kombination von Werten (z.B. eine 2d-matrix von double), aber nicht Mandat ein bestimmtes Speicherformat, kann es Sinn machen, zu definieren, Gleichheit und hash-code in Bezug auf diese Werte. In einem solchen Fall, eine IdentityMatrix with Größe " gleich drei vielleicht sinnvoll vergleichen Sie gleich ein DiagonalMatrix mit DiagonalValues holding {1.0,1.0,1.0}.

    InformationsquelleAutor Jon Skeet

  2. 2

    Die zweite version ist sicher, würde ich sagen, pedantisch. Ihre version, stattdessen Einführung eines ClassCastException weil Sie unter der Annahme, dass die Laufzeit-Typ der Variablen obj ist der Typ Produkt. Das ist nicht wahr, das ist, warum Sie verwenden sollten this.getClass() != obj.getClass() (Sie dieses problem lösen könnte, auch mit instanceof Betreiber).

    Wenn ich

    Product p = new Product();
p.equals("abc");

    Bekomme ich auch eine exception, während ich bekommen sollte false.

    Darüber hinaus verwaltet die product.equals(null) problem, das sollte false zurückgeben, wie es in equals Vertrag-Methode in der Dokumentation. Wenn Sie nicht kümmern, über dies und das tun Sie, man innen gleich:

    ...
Product p = (Product)obj; //obj is null
obj.id //this throws a NullPointerException
    Mit instanceof in einer nicht-finalen Klasse gibt eine Symmetrie problem, wenn die Klasse als Unterklasse definiert.
    Ja, Sie sind richtig. Ich dachte über das überschreiben es wieder in einer Unterklasse..

    InformationsquelleAutor Jack

  3. 1

    Den gemeinsamen idiom verwendet beim überschreiben von equals() ist

    @Override
public boolean equals(Object obj) {
       if (! (obj instanceof Product) ) return false;

       final Product other = (Product) obj;
       if (id != other.id)
           return false;
       return true;
   }

    In der zweiten version die du gepostet hast:

    • der ersten wenn() kann gut sein, für
      Optimierung nur, wenn die folgenden
      Prüfungen sind zu viel teuer. Aber
      ist dies nicht der Fall, so dass nur
      redundanter code ist böse.
    • Die version wird nicht funktionieren, wenn Sie definieren ein Produkt Unterklasse, die
      keine änderung an der Semantik der Methode equals().
      (Zum Beispiel eine Klasse, die
      bietet einigen Komfort-Methode, aber
      keine zusätzlichen internen Zustand der
      - Objekte.) Dies ist wegen der
      Dritten, wenn().

    InformationsquelleAutor ignis

  4. 0

    Nummer 2 ist rechts von Effektive Java - für die sicherste Möglichkeit zum überschreiben der equals. 1 hat ein nullpointer, wenn das Objekt null ist, und es nicht so optimiert wie es sein könnte(muss nicht prüfen, ob obj eine Referenz auf sich selbst)

    InformationsquelleAutor nsfyn55

  5. 0

    Die Lösung von 'Joshua Bloch: Effective Java" ist (unter der Annahme, dass Product nicht eine Superklasse anderen als Object):

    @Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (!(obj instanceof Product)) return false;
    final Product other = (Product) obj;
    if (id != other.id) return false;
    return true;
}

    Ihre erste Lösung leidet an zwei Nachteilen:

    • new Product(1).equals(null) wirft eine NullpointerException, obwohl es angegeben wird false zurückgegeben, im Objekt.equals().
    • new Product(1).equals(new Vector()) wirft eine classcastexception-Fehler, obwohl es angegeben wird false zurückgegeben, im Objekt.equals().

    Beide sind so zu beseitigen, dass die Instanz prüfen. Die if (this == obj) return true; ist oft nützlich für die Effizienz, aber wohl nicht notwendig, hier.

    Die zweite Lösung, die du gepostet hast, macht es schwierig, einen zu schreiben eine Unterklasse von Produkt mit guter Semantik. Wenn Sie eine Unterklasse

    public class SubProduct extends Product {
    SubProduct(int id) {
         super(id);
    }
    ...
}

    haben Sie !new Product(4).equals(new SubProduct(4)). Dies verstößt gegen Liskov ' s susbstitution Prinzip und ist oft vermutlich nicht so gut. Wenn Sie eine Finale Klasse
    die zweite-Lösungen ist die gleiche wie die oben genannten.

    Überlegen Sie, ob SubProduct hat etwas mehr Stand und weitere überschreibungen equals - dann, wenn Sie instanceof Sie am Ende mit a.equals(b) != b.equals(a), die gegen die Object Vertrag. Über die genaue Klasse nicht immer, was Sie wollen in Bezug auf Liskov, aber es nicht ermöglicht das erstellen von Unterklassen, ohne die Object Vertrag. Geschlechter entlang einer Vererbungshierarchie ist im Grunde schmerzhaft 🙁
    Volle Zustimmung. Ich sorgfältig vermieden zu sagen "falsch" ist. Ich war nicht so vorsichtig Lesen der anderen Antworten, jedoch und verpasste Ihr noch mehr prägnante Gegenbeispiele.

    InformationsquelleAutor Christoph Zenger

Schreibe einen Kommentar