Warum ist compareTo auf einem Enum-Finale in Java?

Eine Aufzählung in Java implementiert die ComparableSchnittstelle. Es wäre schön außer Kraft zu setzen gewesen Comparable‚s compareToMethode, aber hier ist es als final markiert. Der Standard natürliche Ordnung auf Enum‚s compareToist die angegebene Reihenfolge.

Weiß jemand, warum eine Java-Aufzählung diese Einschränkung hat?

Aus Gründen der Konsistenz denke ich ... wenn Sie einen enumTyp sehen, wissen Sie sicher , dass seine natürliche Reihenfolge die Reihenfolge ist, in der die Konstanten deklariert werden.

Um dies zu umgehen, können Sie ganz einfach Ihre eigenen erstellen Comparator<MyEnum>und verwenden, wenn Sie eine andere Bestellung benötigen:

enum MyEnum
{
    DOG("woof"),
    CAT("meow");

    String sound;    
    MyEnum(String s) { sound = s; }
}

class MyEnumComparator implements Comparator<MyEnum>
{
    public int compare(MyEnum o1, MyEnum o2)
    {
        return -o1.compareTo(o2); // this flips the order
        return o1.sound.length() - o2.sound.length(); // this compares length
    }
}

Sie können das Comparatordirekt verwenden:

MyEnumComparator c = new MyEnumComparator();
int order = c.compare(MyEnum.CAT, MyEnum.DOG);

oder verwenden Sie es in Sammlungen oder Arrays:

NavigableSet<MyEnum> set = new TreeSet<MyEnum>(c);
MyEnum[] array = MyEnum.values();
Arrays.sort(array, c);    

Weitere Informationen:

• Das Java-Tutorial zu Aufzählungstypen
• Suns Leitfaden zu Aufzählungen
• Class Enum API

Es ist in Ordnung, eine Standardimplementierung von compareTo bereitzustellen, die die Quellcode-Reihenfolge verwendet. es endgültig zu machen war ein Fehltritt von Suns Seite. Die Ordnungszahl berücksichtigt bereits die Deklarationsreihenfolge. Ich bin damit einverstanden, dass ein Entwickler in den meisten Situationen seine Elemente nur logisch ordnen kann, aber manchmal möchte man, dass der Quellcode so organisiert ist, dass Lesbarkeit und Wartung an erster Stelle stehen. Beispielsweise:

  //===== SI BYTES (10^n) =====//

  /** 1,000 bytes. */ KILOBYTE (false, true,  3, "kB"),
  /** 106 bytes. */   MEGABYTE (false, true,  6, "MB"),
  /** 109 bytes. */   GIGABYTE (false, true,  9, "GB"),
  /** 1012 bytes. */  TERABYTE (false, true, 12, "TB"),
  /** 1015 bytes. */  PETABYTE (false, true, 15, "PB"),
  /** 1018 bytes. */  EXABYTE  (false, true, 18, "EB"),
  /** 1021 bytes. */  ZETTABYTE(false, true, 21, "ZB"),
  /** 1024 bytes. */  YOTTABYTE(false, true, 24, "YB"),

  //===== IEC BYTES (2^n) =====//

  /** 1,024 bytes. */ KIBIBYTE(false, false, 10, "KiB"),
  /** 220 bytes. */   MEBIBYTE(false, false, 20, "MiB"),
  /** 230 bytes. */   GIBIBYTE(false, false, 30, "GiB"),
  /** 240 bytes. */   TEBIBYTE(false, false, 40, "TiB"),
  /** 250 bytes. */   PEBIBYTE(false, false, 50, "PiB"),
  /** 260 bytes. */   EXBIBYTE(false, false, 60, "EiB"),
  /** 270 bytes. */   ZEBIBYTE(false, false, 70, "ZiB"),
  /** 280 bytes. */   YOBIBYTE(false, false, 80, "YiB");

Die obige Reihenfolge sieht im Quellcode gut aus, aber der Autor ist nicht der Meinung, dass compareTo funktionieren sollte. Das gewünschte compareTo-Verhalten besteht darin, dass die Reihenfolge nach Anzahl der Bytes erfolgt. Die Reihenfolge des Quellcodes, die dies bewirken würde, verschlechtert die Organisation des Codes.

Als Kunde einer Aufzählung ist es mir egal, wie der Autor seinen Quellcode organisiert hat. Ich möchte jedoch, dass ihr Vergleichsalgorithmus einen Sinn ergibt. Sun hat Quellcode-Schreiber unnötigerweise in eine Bindung gebracht.

Aufzählungswerte werden logisch genau in der Reihenfolge sortiert, in der sie deklariert sind. Dies ist Teil der Java-Sprachspezifikation. Daraus folgt, dass Aufzählungswerte nur verglichen werden können, wenn sie Mitglieder derselben Aufzählung sind. Die Spezifikation möchte ferner sicherstellen, dass die von compareTo () zurückgegebene vergleichbare Reihenfolge mit der Reihenfolge übereinstimmt, in der die Werte deklariert wurden. Dies ist die Definition einer Aufzählung.

Eine mögliche Erklärung ist, dass compareTomit übereinstimmen sollte equals.

Und equalsfür Aufzählungen sollte mit Identitätsgleichheit übereinstimmen ( ==).

Wenn compareToes nicht endgültig ist, kann es mit einem Verhalten überschrieben werden, das nicht mit equalsdem übereinstimmt , was sehr kontraintuitiv wäre.

Wenn Sie die natürliche Reihenfolge der Elemente Ihrer Aufzählung ändern möchten, ändern Sie deren Reihenfolge im Quellcode.