Dlaczego compareTo jest na finale Enum w Javie?

Wyliczenie w Javie implementuje Comparableinterfejs. Byłoby miło, aby zastąpić Comparable„s compareTometody, ale tutaj jest oznaczony jako wersja ostateczna. Domyślną naturalny porządek na Enum„s compareTojest podana kolejność.

Czy ktoś wie, dlaczego wyliczenia Java mają to ograniczenie?

Myślę, że dla spójności ... kiedy widzisz enumtyp, wiesz na pewno , że jego naturalny porządek to kolejność, w której deklarowane są stałe.

Aby obejść ten problem, możesz łatwo utworzyć własną Comparator<MyEnum>i używać jej, gdy potrzebujesz innej kolejności:

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
    }
}

Możesz skorzystać Comparatorbezpośrednio z:

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

lub użyj go w kolekcjach lub tablicach:

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

Dalsza informacja:

• Samouczek języka Java dotyczący typów wyliczeń
• Przewodnik firmy Sun po wyliczeniach
• Class Enum API

Podanie domyślnej implementacji compareTo, która używa kolejności kodu źródłowego, jest w porządku; uczynienie go ostatecznym było błędem ze strony Sun. Porządek porządkowy już uwzględnia kolejność deklaracji. Zgadzam się, że w większości sytuacji programista może po prostu logicznie uporządkować swoje elementy, ale czasami chce się, aby kod źródłowy był zorganizowany w sposób, który sprawia, że ​​czytelność i konserwacja są najważniejsze. Na przykład:

  //===== 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");

Powyższa kolejność wygląda dobrze w kodzie źródłowym, ale autor uważa, że ​​nie tak powinno działać funkcja compareTo. Żądanym zachowaniem compareTo jest uporządkowanie według liczby bajtów. Porządkowanie kodu źródłowego, które by to spowodowało, degraduje organizację kodu.

Jako klient wyliczenia nie obchodziło mnie, jak autor zorganizował swój kod źródłowy. Chciałbym jednak, żeby ich algorytm porównawczy miał jakiś sens. Firma Sun niepotrzebnie związała twórców kodu źródłowego.

Wartości wyliczeń są precyzyjnie uporządkowane logicznie zgodnie z kolejnością, w jakiej są zadeklarowane. Jest to część specyfikacji języka Java. W związku z tym wynika, że ​​wartości wyliczenia można porównać tylko wtedy, gdy są członkami tego samego Enum. Specyfikacja chce dodatkowo zagwarantować, że porównywalna kolejność zwrócona przez funkcję compareTo () jest taka sama, jak kolejność, w której zadeklarowano wartości. To jest właśnie definicja wyliczenia.

Jednym z możliwych wyjaśnień jest to, że compareTopowinno być zgodne z equals.

A equalswyliczenia powinny być zgodne z równością tożsamości ( ==).

Gdyby compareTonie było ostateczne, można by zastąpić to zachowaniem, które nie było zgodne z equals, co byłoby bardzo sprzeczne z intuicją.

Jeśli chcesz zmienić naturalną kolejność elementów wyliczenia, zmień ich kolejność w kodzie źródłowym.