Java에서 Enum의 compareTo가 최종인 이유는 무엇입니까?

Java에서 Enum의 compareTo가 최종인 이유는 무엇입니까?

Java의 enum은 다음을 구현합니다.Comparable인터페이스입니다.다른 사람을 무시하면 좋았을 텐데Comparable의compareTo방법은요, 하지만 여기엔 최종적인 것으로 표시되어 있어요.기본 자연 순서Enum의compareTo는 기재되어 있는 순서입니다.

Java Enum에 이러한 제한이 있는 이유를 아는 사람이 있습니까?

일관성을 위해...을 보면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);    

상세 정보:

• Enum 타입에 관한 Java 튜토리얼
• Sun's Guide to Enums
• 클래스 Enum API

소스 코드 순서를 사용하는 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");

위의 순서는 소스 코드에서는 양호하지만 작성자가 생각하는 compareTo의 작동 방식은 아닙니다.바람직한 compareTo 동작은 바이트 수로 순서를 지정하는 것입니다.이를 가능하게 하는 소스 코드 순서는 코드 구성을 저하시킵니다.

열거의 고객으로서 나는 저자가 그들의 소스코드를 어떻게 구성했는지 전혀 신경 쓰지 않는다.하지만 그들의 비교 알고리즘이 어떤 식으로든 말이 됐으면 좋겠어요.Sun은 불필요하게 소스 코드 라이터를 곤경에 빠뜨렸다.

열거값은 선언된 순서에 따라 논리적으로 정확하게 정렬됩니다.이것은 Java 언어 사양의 일부입니다.따라서 열거값은 동일한 Enum의 멤버일 경우에만 비교할 수 있습니다.이 사양에서는 compareTo()에 의해 반환되는 동등한 순서가 값이 선언된 순서와 동일함을 더욱 보증하려고 합니다.이것이 열거형의 정의입니다.

할 수 있는 중 하나는 '이러다'입니다.compareTo해야 equals.

★★★★★★★★★★★★★★★★★.equals평등(enums)과.==를 참조해 주세요.

ifcompareTo최종적이지 않은 경우, 다음과 일치하지 않는 행동으로 덮어쓸 수 있습니다.equals건건매매매매직직직반반반

열거형 요소의 자연 순서를 변경하려면 소스 코드에서 요소의 순서를 변경합니다.

언급URL : https://stackoverflow.com/questions/519788/why-is-compareto-on-an-enum-final-in-java