Pourquoi compareTo sur un Enum final en Java?

Une énumération en Java implémente l' Comparableinterface. Cela aurait été bien de surcharger Comparablela compareTométhode, mais ici, elle est marquée comme définitive. L'ordre naturel par défaut sur Enumles compareToest l'ordre indiqué.

Est-ce que quelqu'un sait pourquoi une énumération Java a cette restriction?

Par souci de cohérence, je suppose ... quand vous voyez un enumtype, vous savez pertinemment que son ordre naturel est l'ordre dans lequel les constantes sont déclarées.

Pour contourner ce problème, vous pouvez facilement créer le vôtre Comparator<MyEnum>et l'utiliser chaque fois que vous avez besoin d'un ordre différent:

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

Vous pouvez utiliser Comparatordirectement:

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

ou utilisez-le dans des collections ou des tableaux:

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

Informations complémentaires:

• Le didacticiel Java sur les types Enum
• Guide de Sun sur les énumérations
• API Class Enum

Fournir une implémentation par défaut de compareTo qui utilise l'ordre du code source est très bien; le rendre définitif était un faux pas de la part de Sun. L'ordinal tient déjà compte de l'ordre de déclaration. Je suis d'accord que dans la plupart des situations, un développeur peut simplement ordonner logiquement ses éléments, mais parfois on veut que le code source soit organisé de manière à rendre la lisibilité et la maintenance primordiales. Par exemple:

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

L'ordre ci-dessus semble bon dans le code source, mais ce n'est pas la façon dont l'auteur pense que compareTo devrait fonctionner. Le comportement compareTo souhaité est que le tri soit par nombre d'octets. L'ordre du code source qui permettrait que cela se produise dégrade l'organisation du code.

En tant que client d'une énumération, je me fiche de la manière dont l'auteur a organisé son code source. Je veux cependant que leur algorithme de comparaison ait un sens. Sun a inutilement mis les écrivains de code source dans une liaison.

Les valeurs d'énumération sont ordonnées logiquement avec précision en fonction de l'ordre dans lequel elles sont déclarées. Cela fait partie de la spécification du langage Java. Par conséquent, il s'ensuit que les valeurs d'énumération ne peuvent être comparées que si elles sont membres du même Enum. La spécification veut en outre garantir que l'ordre comparable renvoyé par compareTo () est le même que l'ordre dans lequel les valeurs ont été déclarées. C'est la définition même d'une énumération.

Une explication possible est que cela compareTodevrait être cohérent avec equals.

Et equalspour les énumérations doivent être cohérentes avec l'égalité d'identité ( ==).

Si compareTooù être non définitif, il serait possible de le remplacer par un comportement qui n'est pas cohérent avec equals, ce qui serait très contre-intuitif.

Si vous souhaitez modifier l'ordre naturel des éléments de votre énumération, modifiez leur ordre dans le code source.