为什么 compareTo 在 Java 的 Enum 决赛中？

enums java compareto comparable

2022-08-31 10:24:09

Java 中的枚举实现接口。覆盖的方法本来会很好，但在这里它被标记为最终。上的默认自然顺序是列出的顺序。ComparableComparablecompareToEnumcompareTo

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

答案 1

为了保持一致性，我想...当您看到一个类型时，您知道一个事实，即它的自然排序是常量的声明顺序。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);

更多信息：

答案 2

提供使用源代码排序的compareTo的默认实现是可以的;最终成为决赛是Sun的失误。序号已计入申报订单。我同意在大多数情况下，开发人员可以对元素进行逻辑排序，但有时人们希望源代码的组织方式使可读性和维护变得至关重要。例如：


  //===== SI BYTES (10^n) =====//

  /** 1,000 bytes. */ KILOBYTE (false, true,  3, "kB"),
  /** 10⁶ bytes. */   MEGABYTE (false, true,  6, "MB"),
  /** 10⁹ bytes. */   GIGABYTE (false, true,  9, "GB"),
  /** 10¹² bytes. */  TERABYTE (false, true, 12, "TB"),
  /** 10¹⁵ bytes. */  PETABYTE (false, true, 15, "PB"),
  /** 10¹⁸ bytes. */  EXABYTE  (false, true, 18, "EB"),
  /** 10²¹ bytes. */  ZETTABYTE(false, true, 21, "ZB"),
  /** 10²⁴ bytes. */  YOTTABYTE(false, true, 24, "YB"),

  //===== IEC BYTES (2^n) =====//

  /** 1,024 bytes. */ KIBIBYTE(false, false, 10, "KiB"),
  /** 2²⁰ bytes. */   MEBIBYTE(false, false, 20, "MiB"),
  /** 2³⁰ bytes. */   GIBIBYTE(false, false, 30, "GiB"),
  /** 2⁴⁰ bytes. */   TEBIBYTE(false, false, 40, "TiB"),
  /** 2⁵⁰ bytes. */   PEBIBYTE(false, false, 50, "PiB"),
  /** 2⁶⁰ bytes. */   EXBIBYTE(false, false, 60, "EiB"),
  /** 2⁷⁰ bytes. */   ZEBIBYTE(false, false, 70, "ZiB"),
  /** 2⁸⁰ bytes. */   YOBIBYTE(false, false, 80, "YiB");

上面的排序在源代码中看起来不错，但不是作者认为compareTo应该工作的方式。所需的 compareTo 行为是按字节数排序。使这种情况发生的源代码排序会降低代码的组织质量。

作为枚举的客户端，我不能不在乎作者如何组织他们的源代码。不过，我确实希望他们的比较算法具有某种意义。Sun不必要地将源代码编写者置于绑定中。