为什么compareTo在Java上的Enum final?

neu*_*242 87 java enums compareto comparable

Java中的枚举实现了Comparable接口.这本来是很好的覆盖ComparablecompareTo方法,但在这里它被标记为最终.Enum's 的默认自然顺序compareTo是列出的顺序.

有谁知道为什么Java枚举有这个限制?

Zac*_*ena 117

为了保持一致性我想......当你看到一个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
    }
}
Run Code Online (Sandbox Code Playgroud)

您可以Comparator直接使用:

MyEnumComparator c = new MyEnumComparator();
int order = c.compare(MyEnum.CAT, MyEnum.DOG);
Run Code Online (Sandbox Code Playgroud)

或在集合或数组中使用它:

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

更多的信息:

  • 是的,它确实.新的MyEnumComparator.compare(enum1,enum2).Etvoilá. (6认同)
  • @kbolino:比较器可能是enum类中的嵌套类。它可以存储在枚举的“ LENGTH_COMPARATOR”静态字段中。这样,对于使用枚举的任何人来说都很容易找到。 (2认同)
  • 我对你的“compare”方法有两个“return”语句一个接一个的事实感到困惑。请你解释一下吗? (2认同)

小智 35

提供使用源代码排序的compareTo的默认实现很好; 让它最终成为Sun的一个失误.序数已经占据了申报单.我同意在大多数情况下,开发人员可以在逻辑上对其元素进行排序,但有时人们希望源代码的组织方式使可读性和维护成为最重要的.例如:


  //===== 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");
Run Code Online (Sandbox Code Playgroud)

上面的顺序在源代码中看起来很好,但不是作者认为compareTo应该如何工作.所需的compareTo行为是按字节数排序.导致这种情况发生的源代码排序会降低代码的组织.

作为枚举的客户,我不在乎作者如何组织他们的源代码.但我确实希望他们的比较算法能够产生某种意义.Sun不必要地将源代码编写器置于绑定中.

  • 同意,我希望我的枚举能够有一个类似的业务,而不是一个如果有人不注意就可以破坏的订单. (3认同)

Mar*_*nor 6

枚举值根据声明的顺序在逻辑上精确排序.这是Java语言规范的一部分.因此,如果枚举值是同一枚举的成员,则只能进行比较.规范要进一步保证compareTo()返回的可比订单与声明值的顺序相同.这是枚举的定义.