Чому compareTo на фіналі Enum у Java?

Enum в Java реалізує Comparableінтерфейс. Було б добре , щоб перевизначити Comparable«s compareToметод, але тут він позначений як остаточний. Природний порядок по замовчуванням на Enum«s compareToє перерахованим порядком.

Хтось знає, чому перелічення Java мають це обмеження?

Для узгодженості, я здогадуюсь ... коли ви бачите enumтип, ви точно знаєте , що його природне впорядкування - це порядок, в якому оголошуються константи.

Щоб обійти це, ви можете легко створити свій власний Comparator<MyEnum>і використовувати його, коли вам потрібно інше впорядкування:

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

Ви можете використовувати Comparatorбезпосередньо:

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

або використовувати його в колекціях або масивах:

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

Додаткова інформація:

• Підручник Java щодо типів Enum
• Sun's Guide for Enums
• API класу Enum

Забезпечення реалізації за замовчуванням порівнянняTo, яка використовує впорядкування вихідного коду - це нормально; зробити його остаточним було помилковим кроком з боку Сонця. Порядковий номер вже враховує порядок декларування. Я згоден з тим, що у більшості ситуацій розробник може просто логічно впорядковувати свої елементи, але іноді хочеться, щоб вихідний код був організований таким чином, щоб читабельність та обслуговування були першорядними. Наприклад:

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

Вищевказане впорядкування виглядає непогано у вихідному коді, але не так, як вважає автор, слід порівнювати To Бажана поведінка порівнянняДля того, щоб упорядкування здійснювалось за кількістю байтів. Впорядкування вихідного коду, яке могло б зробити це, погіршує організацію коду.

Як клієнту переліку, мені було байдуже, як автор організував їхній вихідний код. Однак я хочу, щоб їх алгоритм порівняння мав якийсь сенс. Sun надто непотрібно поставив розробників вихідного коду.

Значення перерахування точно впорядковуються логічно відповідно до порядку їх оголошення. Це частина специфікації мови Java. Звідси випливає, що значення перерахування можна порівнювати, лише якщо вони є членами одного переліку. Специфікація хоче додатково гарантувати, що порівнянний порядок, який повертає функція compareTo (), такий самий, як і порядок, у якому були оголошені значення. Це саме визначення переліку.

Одне з можливих пояснень полягає в тому, що воно compareToповинно відповідатиequals .

А equalsпереліки повинні відповідати рівності ідентичності (== ).

Якщо compareToде не бути остаточним, можна було б замінити його поведінкою, яка не узгоджувалась equals, що було б дуже інтуїтивно зрозумілим.

Якщо ви хочете змінити природний порядок елементів вашого переліку, змініть їх порядок у вихідному коді.