জাভাতে একটি এনাম Comparableইন্টারফেস প্রয়োগ করে । এটিকে ওভাররাইড করতে চমৎকার হত Comparable'র compareToপদ্ধতি, কিন্তু এখানে এটি চূড়ান্ত হিসেবে চিহ্নিত হচ্ছে। ডিফল্ট প্রাকৃতিক অর্ডার Enumএর compareToতালিকাভুক্ত ক্রম।
কেউ কি জানেন যে জাভা এনামদের কেন এই বিধিনিষেধ আছে?
উত্তর:
ধারাবাহিকতার জন্য আমি অনুমান করি ... আপনি যখন কোনও 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);
আরো তথ্য:
MyEnumComparatorকোনও রাজ্য নেই, এটি কেবল একটি সিঙ্গলটন হওয়া উচিত, বিশেষত যদি আপনি @ বোম্বের পরামর্শ অনুসারে কাজ করছেন; পরিবর্তে, আপনি MyEnumComparator.INSTANCE.compare(enum1, enum2)অপ্রয়োজনীয় অবজেক্ট তৈরি এড়ানোর মতো কিছু করতে চান
LENGTH_COMPARATORএনামের স্ট্যাটিক ক্ষেত্রে সংরক্ষণ করা যেতে পারে । যেভাবে এনাম ব্যবহার করছেন তার পক্ষে এটি খুঁজে পাওয়া সহজ হবে।
উত্স-কোড ক্রম ব্যবহার করে তুলনা করার জন্য একটি ডিফল্ট বাস্তবায়ন প্রদান করা ঠিক আছে; এটি চূড়ান্ত করা সূর্যের পক্ষে একটি মিসটপ ছিল। অর্ডিনাল ইতিমধ্যে ঘোষণার আদেশের জন্য অ্যাকাউন্ট করে। আমি সম্মত হই যে বেশিরভাগ পরিস্থিতিতে একজন বিকাশকারী কেবল যুক্তিযুক্তভাবে তাদের উপাদানগুলি অর্ডার করতে পারে, তবে কখনও কখনও কেউ উত্স কোডটি এমনভাবে সাজানো চায় যা পাঠযোগ্যতা এবং রক্ষণাবেক্ষণকে সর্বজনীন হতে পারে। উদাহরণ স্বরূপ:
//===== 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");
উপরোক্ত ক্রমটি সোর্স কোডে ভাল দেখাচ্ছে, তবে লেখক কীভাবে তুলনামূলকভাবে কাজ করবে তা বিশ্বাস করে না। পছন্দসই তুলনা করার আচরণটি বাইটের সংখ্যা অনুসারে অর্ডার করা। উত্স-কোড ক্রম যা এমনটি ঘটবে তা কোডের সংস্থাকে হ্রাস করে।
একটি গণনার ক্লায়েন্ট হিসাবে লেখক কীভাবে তাদের উত্স কোডটি সাজিয়েছেন আমি তার কম যত্ন নিতে পারিনি। যদিও আমি তাদের তুলনা অ্যালগরিদম কিছু ধরণের বোধ তৈরি করতে চাই। সূর্য অযথা সোর্স কোড লেখকদের একটি বাঁধাই করে ফেলেছে।
ক্রম মানগুলি ঘোষিত আদেশ অনুসারে যথাযথভাবে যুক্তিযুক্তভাবে অর্ডার করা হয়। এটি জাভা ভাষার নির্দিষ্টকরণের অংশ of সুতরাং এটি অনুসরণ করে যে গণনা মানগুলি কেবল একই এনুমের সদস্য হলে তুলনা করা যায়। স্পেসিফিকেশনটি আরও গ্যারান্টি দিতে চায় যে তুলনাযোগ্য আদেশটি তুলনাযোগ্য () দ্বারা ফেরত দেওয়া একই ক্রম হিসাবে মানগুলি ঘোষিত হয়েছিল। এটি একটি গণনার খুব সংজ্ঞা।
একটি সম্ভাব্য ব্যাখ্যা এটি compareToসামঞ্জস্যপূর্ণ হওয়া উচিত equals।
এবং equalsএনামগুলির জন্য পরিচয়ের সমতা ( ==) এর সাথে সামঞ্জস্য করা উচিত ।
যদি compareToঅ-চূড়ান্ত হয় তবে এটি এমন আচরণের সাথে ওভাররাইড করা সম্ভব হবে যা সামঞ্জস্যপূর্ণ নয় equals, যা খুব পাল্টা-স্বজ্ঞাত হবে।
আপনি যদি এনামের উপাদানগুলির প্রাকৃতিক ক্রম পরিবর্তন করতে চান তবে উত্স কোডে তাদের ক্রমটি পরিবর্তন করুন।