Substitution de la méthode equals vs création d'une nouvelle méthode

Question

J'ai toujours pensé que l' .méthode equals() de java devrait être remplacé à être spécifiques à la classe que vous avez créé.En d'autres termes à rechercher l'équivalence de deux instances différentes, plutôt que deux références à la même instance.Toutefois, j'ai rencontré d'autres programmeurs qui semblent penser que la valeur par défaut de l'objet de comportement ne doit être laissé seul, et une nouvelle méthode créée pour tester l'équivalence de deux objets de la même classe.

Quels sont les argument pour et contre la substitution de la méthode equals?

Answer 1

Substitution de la méthode equals est nécessaire si vous voulez tester l'équivalence dans la norme de la bibliothèque de classes (par exemple, d'assurer un java.util.Set contient des éléments uniques ou à l'aide d'objets comme des clés en java.util.Les objets de la carte).

Remarque, si vous substituez est égal, assurez-vous d'honneur de l'API contrat, comme décrit dans la documentation.Par exemple, assurez-vous également de remplacer Objet.hashCode:

Si deux objets sont égaux selon la equals(Object) méthode, puis l'appel de la méthode hashCode sur chacun de les deux objets doivent produire les mêmes résultat sous forme d'entier.

EDIT:Je n'ai pas ce post comme une réponse complète sur le sujet, donc je vais echo Fredrik Kalseth que impérieuse d'égal à égal qui fonctionne le mieux pour des objets immuables.Pour citer l'API pour Carte:

Note:un grand soin doit être exercé si mutable objets sont utilisés comme une carte de clés.Le comportement d'une carte n'est pas spécifié si la valeur d'un objet est modifié une manière qui affecte égale comparaisons tandis que l'objet est un élément clé dans la carte.

Answer 2

Je vous recommande fortement de ramasser une copie de l'Effectif de Java et de la lecture par le biais de l'article 7 obéir à la est égal à contrat.Vous devez être prudent si vous écrasez égale pour mutable objets, comme la plupart des collections telles que des Cartes et des Jeux de l'utilisation équivaut à déterminer l'équivalence, et la mutation d'un objet contenu dans une collection pourrait conduire à des résultats inattendus.Brian Goetz a aussi une assez bonne vue d'ensemble de la mise en œuvre de equals et hashCode.

Answer 3

Vous devez "jamais" override est égal à & getHashCode pour mutable objets - cela va de pour les .net et Java à la fois.Si vous le faites, et d'utiliser un tel objet comme clé dans f.ex un dictionnaire et puis changement cet objet, vous serez en difficulté parce que le dictionnaire s'appuie sur le hashcode de trouver l'objet.

Voici un bon article sur le sujet: http://weblogs.asp.net/bleroy/archive/2004/12/15/316601.aspx

Answer 4

@David Schlosnagle mentions mentions Josh du Bloch Efficace Java -- c'est un à lire absolument pour tous les développeurs Java.

Il y a un problème connexe:pour immuable des objets de valeur, vous devriez également considérer primordial compare_to.Le libellé standard pour s'ils diffèrent, c'est dans l' Comparable API:

C'est généralement le cas, mais n'est pas strictement nécessaire que (compare(x, y)==0) == (x.equals(y)).De manière générale, toute comparaison qui viole cette condition doit clairement indiquer ce fait.Le texte est "Remarque:ce comparateur impose des ordonnancements qui sont incompatibles avec égal à égal."

Answer 5

La méthode Equals est destiné à comparer les références.Donc, il ne devrait pas être remplacé pour modifier son comportement.

Vous devez créer une nouvelle méthode de test de l'équivalence dans les différentes instances en cas de besoin (ou utiliser la méthode CompareTo dans certains .NET classes)

Answer 6

Pour être honnête, en Java il n'est pas vraiment un argument contre le primordial est égal à.Si vous avez besoin de comparer des instances pour l'égalité, alors qu'est ce que vous faites.

Comme mentionné ci-dessus, vous devez être conscient du contrat avec hashCode, et , de même, attention aux pièges autour de la Comparable interface - dans presque toutes les situations, vous voulez le ordre naturel tel que défini par Comparable à compatible avec égal à égal (voir la BigDecimal doc api pour les canonique contre-exemple)

Création d'une nouvelle méthode pour décider de l'égalité, tout à fait à part de ne pas travailler avec l'existant de la bibliothèque de classes, les mouches sur le visage de Java convention un peu.

Answer 7

Vous devriez seulement besoin de remplacer la equals() méthode si vous souhaitez un comportement particulier lors de l'ajout d'objets triés structures de données (SortedSet etc.)

Lorsque vous faites cela, vous devriez également de remplacer hashCode().

Voir ici pour une explication complète.