Java, Warum wird vorausgesetzt, dass Objekte gleich sind, wenn compareTo () 0 zurückgibt?

Let ' s haben einen Klasse Person. Person hat einen Namen und Höhe.

Equals-und hashCode() berücksichtigt nur die Namen. Person vergleichbar ist (oder wir implementieren Komparator für es, ist egal welche). Personen werden verglichen, indem die Höhe.

Scheint es vernünftig zu erwarten, dass eine situation, wo zwei verschiedene Personen haben gleiche Höhe, aber zB. TreeSet verhält sich wie comapareTo()==0 bedeutet gleich, die nicht nur gleiche Größe.

Um dies zu vermeiden, den Vergleich kann Sekundär zu betrachten, etwas anderes, wenn Größe ist die gleiche, aber dann kann es nicht verwendet werden, zu erkennen gleicher Größe von verschiedenen Objekten.

Beispiel:

import java.util.Comparator;
import java.util.HashSet;
import java.util.Objects;
import java.util.Set;
import java.util.TreeSet;

public class Person implements Comparable<Person> {

private final String name;
private int height;

public Person(String name,
        int height) {
    this.name = name;
    this.height = height;
}

public int getHeight() {
    return height;
}

public void setHeight(int height) {
    this.height = height;
}

public String getName() {
    return name;
}

@Override
public int compareTo(Person o) {
    return Integer.compare(height, o.height);
}

public boolean equals(Object obj) {
    if (obj == null) {
        return false;
    }
    if (getClass() != obj.getClass()) {
        return false;
    }
    final Person other = (Person) obj;
    if (!Objects.equals(this.name, other.name)) {
        return false;
    }
    return true;
}

public int hashCode() {
    int hash = 5;
    hash = 13 * hash + Objects.hashCode(this.name);
    return hash;
}

public String toString() {
    return "Person{" + name + ", height = " + height + '}';
}

public static class PComparator1 implements Comparator<Person> {

    @Override
    public int compare(Person o1,
            Person o2) {
        return o1.compareTo(o2);
    }
}

public static class PComparator2 implements Comparator<Person> {

    @Override
    public int compare(Person o1,
            Person o2) {
        int r = Integer.compare(o1.height, o2.height);
        return r == 0 ? o1.name.compareTo(o2.name) : r;
    }
}

public static void test(Set<Person> ps) {
    ps.add(new Person("Ann", 150));
    ps.add(new Person("Jane", 150));
    ps.add(new Person("John", 180));
    System.out.println(ps.getClass().getName());
    for (Person p : ps) {
        System.out.println(" " + p);
    }
}

public static void main(String[] args) {
    test(new HashSet<Person>());
    test(new TreeSet<Person>());
    test(new TreeSet<>(new PComparator1()));
    test(new TreeSet<>(new PComparator2()));
}
}

Ergebnis:

java.util.HashSet
 Person{Ann, height = 150}
 Person{John, height = 180}
 Person{Jane, height = 150}

java.util.TreeSet
 Person{Ann, height = 150}
 Person{John, height = 180}

java.util.TreeSet
 Person{Ann, height = 150}
 Person{John, height = 180}

java.util.TreeSet
 Person{Ann, height = 150}
 Person{Jane, height = 150}
 Person{John, height = 180}

Haben Sie eine Idee, warum es so ist?

InformationsquelleAutor der Frage Alpedar | 2011-08-29

16

Auszug aus der java.util.SortedSet javadoc:

Beachten Sie, dass die Reihenfolge beibehalten, indem eine sortierte Menge (ob oder nicht
einen expliziten comparator vorgesehen ist) muss konsistent mit equals wenn
die sortierte Menge ist, um richtig implementieren die Schnittstelle. (Siehe die
Vergleichbare Schnittstelle oder interface Comparator für eine genaue definition
der konsistent mit equals.) Dies ist so, weil es die Schnittstelle ist
definiert in Bezug auf die equals-operation, aber eine sortierte Menge führt
alle element-Vergleiche, die mit Ihrer compareTo (oder vergleichen) - Methode, so
zwei Elemente gelten als gleich, die von dieser Methode sind, aus der
Standpunkt des sortierten Satzes, gleich. Das Verhalten, eine sortierte Menge ist
gut definiert, auch wenn Ihre Bestellung ist inkonsistent mit equals; es nur
fehl gehorchen dem Allgemeinen Vertrag für die Schnittstelle.

Also, in anderen Worten, SortedSet Pausen (oder "erweitert") die Allgemeinen Verträge für Object.equals() und Comparable.compareTo. Finden Sie den Vertrag für compareTo:

Es wird dringend empfohlen, ist aber nicht unbedingt erforderlich, dass
(x.compareTo(y)==0) == (x.equals(y)). Allgemein gesprochen, alle Klasse
implementiert, dass der Vergleichbare Schnittstelle und verletzt diese Bedingung
sollte genau diese Tatsache hinweisen. Die empfohlene Sprache "Hinweis:
diese Klasse hat eine Natürliche Ordnung, die inkonsistent mit equals."

InformationsquelleAutor der Antwort Lukas Eder
10

Es wird empfohlen, dass compareTo gibt nur 0 wenn ein Anruf zu equals auf die gleichen Objekte zurück true:

Die Natürliche der Bestellung für eine Klasse C ist gesagt zu werden, konsistent mit equals, wenn, und nur wenn e1.compareTo(e2) == 0 hat den gleichen booleschen Wert wie e1.equals(e2) für alle e1-und e2 der Klasse C. zu Beachten ist, dass die null ist nicht eine Instanz einer Klasse, und e.compareTo(null) werfen sollte eine NullPointerException, obwohl e.equals(null) false zurück.

(Aus der JDK 1.6 Javadocs)

InformationsquelleAutor der Antwort nfechner
5

TreeSet funktioniert nicht mit hash-codes und Gleichheit - es funktioniert nur auf der Grundlage des Komparators, die es Ihnen. Beachten Sie, dass die Javadoc Staaten:

Beachten Sie, dass die Bestellung gewartet, die von einem (unabhängig davon, ob oder nicht eine ausdrückliche Komparator vorgesehen ist) muss konsistent mit equals, wenn es um richtig implementieren die Schnittstelle. (Siehe Vergleichbare oder Komparator für eine genaue definition konsistent mit equals.) Dies ist so, weil es die Schnittstelle definiert ist, in Bezug auf die equals-operation, aber ein TreeSet Instanz führt alle element-Vergleiche, die mit Ihrer compareTo (oder vergleichen) - Methode, so werden zwei Elemente gelten als gleich, die von dieser Methode sind, aus der Sicht der Satz, gleich. Das Verhalten des set ist gut definiert, auch wenn Ihre Bestellung ist inkonsistent mit equals; es schlägt fehl, um zu gehorchen dem Allgemeinen Vertrag für die Schnittstelle.

In Ihrem Fall, Ihr Vergleich *nicht im Einklang mit equalsso dass Ihr set nicht gehorchen dem Allgemeinen Vertrag für die Set.

Warum nicht fügen Sie einfach weitere Aspekte für den Vergleich, so dass nur gleiche Elemente vergleichen mit einem Ergebnis von 0?

InformationsquelleAutor der Antwort Jon Skeet
1

können Sie es beheben, indem man den Namen für einen anderen Vergleich, wenn die Höhen gleich sind
```
@Override
public int compareTo(Person o) {
    if(height == o.height)return name.compareTo(o.name);

    return Integer.compare(height, o.height);
}
```
da die Namen eindeutig sind, wird dies nur gibt 0 zurück, wenn this.equals(o)

InformationsquelleAutor der Antwort ratchet freak
1

Es wird dringend empfohlen, ist aber nicht streng erforderlich, dass (x.compareTo(y)==0) == (x.equals(y)) [Eins]

So ist es fein, dass du im Vergleich mit anderen Kriterien als die verwendet werden auf equals gewährt, die Sie dokumentieren.

Aber es wäre besser, wenn Ihr zu vergleichen, durch die gleichen Kriterien und, falls erforderlich, geben Sie einen benutzerdefinierten Komparator, die sich auf die neuen Kriterien ( Höhe in dem Fall der Mensch )

InformationsquelleAutor der Antwort OscarRyz
0

Geben, wenn Sie Person, die einen Komparator, der vergleicht Instanzen auf das height-Attribut der Person, es wirklich bedeutet, dass zwei-Personen-Instanzen sind gleich, wenn Sie die gleiche Höhe haben.
Sie haben zu einem Komparator, der spezifisch ist für die Klasse Person.

InformationsquelleAutor der Antwort S.L. Barth

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.