هل يجب أن أشعر بالقلق إزاء تنفيذ المقارنة/متساوٍ/هاشك الرمز؟

Question

أنا في منتصف Qa'ing مجموعة من التعليمات البرمجية ووجدت العديد من الحالات التي يكون فيها المطور لديه DTO الذي ينفذ قابلة للمقارنة. هذا DTO لديه 7 أو 8 حقول فيه. تم تنفيذ طريقة المقارنة في مجال واحد فقط:

private DateMidnight field1;  //from Joda date/time library

public int compareTo(SomeObject o) {
   if (o == null) {
      return -1;
   }
   return field1.compareTo(o.getField1());
}

وبالمثل ، يتم تجاوز طريقة متساوية وتتلخص بشكل أساسي إلى:

return field1.equals(o.getField1());

وأخيراً تطبيق طريقة Hashcode هو:

return field1.hashCode;

field1 يجب ألا نكون فارغًا أبدًا وسنكون فريدًا عبر هذه الكائنات (أي يجب ألا نحصل على كائنين مع نفس الشيء field1).

لذا ، فإن التطبيقات متسقة وهو أمر جيد ، لكن هل يجب أن أشعر بالقلق من استخدام مجال واحد فقط؟ هل هذا غير عادي؟ هل من المحتمل أن تسبب مشاكل أم تخلط بين المطورين الآخرين؟ أفكر في السيناريو حيث يتم تمرير قائمة هذه الكائنات ويستخدم مطور آخر خريطة أو مجموعة من Somesort ويحصل على سلوك غير عادي من هذه الكائنات. أي أفكار موضع تقدير. شكرًا!

Answer 1

أظن أن هذه حالة "فوز الاستخدام الأول" - شخص يحتاج إلى فرز مجموعة من هذه الكائنات أو وضعها في خريطة التجزئة ، و أنهم اهتم فقط بالتاريخ. أسهل طريقة للتنفيذ هي تجاوز equals/hashCode وتنفيذ Comparable<T> بالطريقة التي قلتها.

بالنسبة للفرز المتخصص ، سيكون التنفيذ هو النهج الأفضل Comparator<T> في فئة مختلفة ... لكن Java ليس لديها أي فئة مكافئة لاختبار المساواة ، لسوء الحظ. أنا أعتبرها ضعفًا كبيرًا في مجموعات Java ، لأكون صادقًا.

على افتراض هذا حقا ليس "المقارنة الطبيعية والواضحة" ، إنها بالتأكيد تنبعث منها رائحة التصميم ... ويجب أن تكون بتوثيق بعناية فائقة.

Answer 2

بالمعنى الدقيق للكلمة ، هذا ينتهك المواصفات المماثلة:

http://download.oracle.com/javase/6/docs/api/java/lang/comparable.html

لاحظ أن NULL ليس مثيلًا لأي فئة ، ويجب أن يرمي E.COMPARETO (NULL) nullpointerxception على الرغم من أن E.equals (NULL) يعيد خطأ.

وبالمثل ، يبدو مثل equals الطريقة سوف ترمي npe على equals(null) بدلا من العودة false (ما لم تكن بالطبع "غلي" من رمز المناولة الفارغ).

هل من المحتمل أن تسبب مشاكل أم تخلط بين المطورين الآخرين؟

ربما ، ربما لا. يعتمد الأمر حقًا على حجم مشروعك ومدى انتشاره/"قابل لإعادة الاستخدام"/من المتوقع استخدام رمز مصدر الكائن الخاص بك منذ فترة طويلة:

• استخدام صغير/قصير العمر/محدود == ربما ليس مشكلة.
• استخدام كبير/طويل الأمد/واسع النطاق == قد يتسبب التنفيذ المضاد للبديه في مشاكل مستقبلية

Answer 3

يجب ألا تهتم به ، إذا كان الحقل 1 فريدة من نوعها حقا. إذا لم يكن الأمر كذلك ، فقد تواجه مشاكل. على أي حال ، نصيحتي هي إجراء بعض اختبارات الوحدة. يجب أن تظهر الحقيقة.

Answer 4

لا أعتقد أنك بحاجة إلى القلق. يتم الاحتفاظ بالعقد بين الطرق الثلاثة وهو متسق.

سواء كان ذلك صحيح من وجهة نظر منطق العمل هو سؤال مختلف.

إذا كان EG Field1 يقوم بتعيين مفتاح أساسي في قاعدة البيانات ، فسيكون ذلك صحيحًا تمامًا. إذا كان Field1 هو "الاسم الأول" للشخص ، فسأكون قلقًا