为什么Java中枚举上的compareTo是final?

为了一致性,我想。。。当你看到一个 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);    

进一步资料:

• The Java Tutorial on Enum Types
• Sun's Guide to Enums
• Class Enum API

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

上面的排序在源代码中看起来不错,但作者认为compareTo不应该这样工作。所需的比较行为是按字节数排序。使这种情况发生的源代码顺序降低了代码的组织。

作为一个枚举的客户,我非常关心作者如何组织他们的源代码。不过,我确实希望他们的比较算法有某种意义。Sun不必要地让源代码编写人员陷入困境。

一种可能的解释是 compareTo 应符合 equals .

对于枚举,应与标识相等一致( == ).

如果 在非最终性的情况下,可以使用与本协议不一致的行为来覆盖该协议 等于 ,这将非常违反直觉。