Dois-je être préoccupé par ce compareTo / equals / mise en œuvre de hashCode?

Question

Je suis au milieu de QA'ing un tas de code et ont trouvé plusieurs cas où le développeur a un DTO qui implémente Comparable. Cette DTO a 7 ou 8 champs en elle. La méthode compareTo a été mis en œuvre sur un seul champ:

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

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

De même, la méthode equals est surchargée et se résume essentiellement à:

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

et enfin la mise en œuvre de la méthode hashcode est:

return field1.hashCode;

field1 ne doit jamais être nul et sera unique à travers ces objets (à savoir que nous ne devrions pas avoir deux objets avec le même field1).

Ainsi, les mises en œuvre sont cohérentes qui est bon, mais dois-je craindre que seul champ est utilisé? Est-ce inhabituel? Est-il susceptible de causer des problèmes ou d'autres développeurs Confuse? Je pense à un scénario dans lequel une liste de ces objets sont passés autour et un autre développeur utilise une carte ou un ensemble de somesort et obtient un comportement inhabituel de ces objets. Toutes les pensées appréciées. Merci!

Answer 1

Je pense que cela est un cas de « première utilisation gagne » - quelqu'un nécessaire pour trier une collection de ces objets ou les mettre dans une carte de hachage, et ils ne se souciaient de la date. La meilleure façon de mettre en œuvre qui devait passer outre equals / hashCode et mettre en œuvre Comparable<T> de la manière que vous avez dit.

Pour le tri spécialisé, une meilleure approche serait de mettre en œuvre Comparator<T> dans une autre classe ... mais Java ne dispose d'aucune classe équivalente pour les tests d'égalité, malheureusement. Je considère comme une faiblesse majeure dans les collections Java, pour être honnête.

En supposant que ce vraiment est pas « une comparaison naturelle et évidente », ça sent certainement en termes de conception ... et devrait être document très attentivement.

Answer 2

A strictement parler, cela viole la spécification Comparable:

http://download.oracle.com/ JavaSE / 6 / docs / api / java / lang / Comparable.html

  

Notez que nul n'est pas une instance d'une classe, et e.compareTo (null) devrait lancer une NullPointerException même si e.equals (null) retourne false.

De même, il ressemble à la méthode de equals jetteront NPE sur equals(null) au lieu de retourner false (à moins bien sûr que vous « fait bouillir » le code de gestion null).

  

est-il susceptible de causer des problèmes ou confondez d'autres développeurs?

Peut-être, peut-être pas. Cela dépend vraiment de la taille de votre projet et l'ampleur / « réutilisable » / long vécu votre code source d'objet devrait être utilisé:

• Petit / de courte durée / utilisation limitée == probablement pas un problème.
• Large / longue durée / utilisation généralisée == mise en œuvre de contre-intuitif peut causer des problèmes futurs

Answer 3

vous ne devriez pas être concerné par, si Field1 est vraiment uniques . S'il s `pas, vous pouvez avoir des problèmes. Quoi qu'il en soit, je vous conseille de faire quelques tests unitaires. Ils doivent montrer la vérité.

Answer 4

Je ne pense pas que vous devez être concerné. Le contrat entre les trois méthodes est maintenue et il est cohérent.

Que ce soit correct d'un point de vue de la logique métier est une autre question.

Si par exemple field1 cartes à une clé primaire dans la base de données, il est parfaitement valide. Si field1 est le « prenom » d'une personne, je serais inquiet