لماذا compareTo على التعداد النهائي في جافا ؟

Question

وهو التعداد في جافا تنفذ Comparable واجهة.كان من الجميل أن تجاوز Comparable's compareTo الطريقة لكن هنا الأمر وضع علامة كنهائي.الافتراضي النظام الطبيعي على Enum's compareTo هو سرد النظام.

لا أحد يعرف لماذا جافا enums يكون هذا القيد ؟

Answer 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);    

مزيد من المعلومات:

• جافا البرنامج التعليمي على أنواع التعداد
• الشمس دليل Enums
• الطبقة التعداد API

Answer 2

وتوفير تطبيق الافتراضي compareTo يستخدم التعليمات البرمجية المصدر ترتيب على ما يرام. مما يجعل من المباراة النهائية كان خطوة خاطئة من جانب الشمس. ترتيبي حسابات بالفعل لأمر الإعلان. أوافق على أن في معظم الحالات مطور يمكن فقط منطقيا تأمر عناصرها، ولكن في بعض الأحيان أحد يريد شفرة المصدر نظمت بطريقة تجعل القراءة والصيانة لهي الراجحة. على سبيل المثال:

  //===== 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 المطلوب هو أن يكون الترتيب يكون حسب عدد بايت. ترتيب التعليمات البرمجية المصدر من شأنه أن يجعل ذلك يحدث يحط تنظيم التعليمات البرمجية.

وكعميل من تعداد أنا لا يمكن أن الرعاية أقل كيف نظم المؤلف شيفرتها المصدرية. أريد خوارزمية مقارنة لجعل بعض نوع من الشعور، وإن كان. الشمس قد وضعت دون داع شفرة المصدر الكتاب في مأزق.

Answer 3

يتم ترتيب

والقيم تعداد بالضبط منطقيا وفقا للترتيب يتم الإعلان عنها. هذا هو جزء من مواصفات لغة جافا. ولذلك يترتب على ذلك أن قيم التعداد يمكن مقارنتها إلا إذا كانوا أعضاء في نفس التعداد. مواصفات يريد مواصلة ضمان أن النظام مقارنة النحو الذي عاد compareTo () هو نفس الترتيب الذي تم الإعلان القيم. هذا هو التعريف الدقيق للتعداد.

Answer 4

وأحد التفسيرات المحتملة هو أن compareTo ينبغي أن تكون متسقة مع equals.

وequals لتتضمن التعدادات ينبغي أن تكون متسقة مع المساواة بين الهوية (==).

إذا compareTo حيث أن عدم النهائي سيكون من الممكن تجاوز ذلك مع السلوك الذي لم يكن يتفق مع equals، والتي ستكون جدا مضادة بديهية.

Answer 5

إذا كنت تريد تغيير النظام الطبيعي للعناصر التعداد الخاص بك، تغيير ترتيبها في شفرة المصدر.