32 votes

Nature transitive de la méthode des égaux

Le contrat d' equals(object) méthode spécifie 4 propriétés à suivre: Réflexive, Symétrique, Transitive et Cohérente. Bien que je comprenne le danger de ne pas être Réflexive, Symétrique et Uniforme , et peut certainement d'accord il est bon de suivre transitive, je me demandais quel mal pourrait apporter si sa violation de la propriété Transitive?

En particulier, ce qui de la bibliothèque Java (ou de diverses bibliothèques tierces) besoin de la dépendance à l'égard equals à être transitive de travailler correctement? Dans ma compréhension, l'Collections cadre de travail si les 3 autres propriétés sont bien mises en œuvre.

42voto

phihag Points 89765

Supposons trois objets a,b,c

a == a, b == b, c == c (reflexive)
a == b, b == a
b == c, c == b
a != c, c != a

(Pseudo-code, x == y représente x.equals(y)).

Maintenant, nous allons ajouter les objets d'un ensemble:

Set s = new HashSet(); // Set implementation doesn't matter
s.add(b); // s = [b]
s.add(a); // s doesn't change, because a == b
s.add(c); // s doesn't change, because c == b

En revanche, si nous étions à ajouter dans un ordre différent:

Set s = new HashSet();
s.add(a); // s = [a]
s.add(b); // s doesn't change, because b == a
s.add(c); // s = [a,c], because c != a

C'est clairement contre-intuitive, et ne correspond pas au comportement que l'on attend d'un jeu. Par exemple, cela signifierait que l'union de deux ensembles (c'est à dire l'état de s après l' s.addAll(someOtherSet)) pourrait dépendre de la mise en œuvre (ordre des éléments) de someOtherSet.

9voto

Gandalf Points 1751

Pour le moment, je ne suis pas au courant d'une API Java qui a des problèmes avec l'absence de transitivité. (Je suis encore en train de réfléchir pour un exemple).

Mais qui est indépendante de celle, transitivité est requis pour l'égalité, parce que c'est la mathématique algébrique définition de la relation d'égalité. http://en.wikipedia.org/wiki/Equality_(mathématiques)

Si la transitivité n'est pas présent, la méthode ne doit pas être appelée est égal, parce que ce serait trompeur de prendre en compte l'attente d'une audience ou à la lecture de "l'égalité". Ce serait en contradiction avec le principe de moindre surprise. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

[MODIFIER]

La chose intéressante à ce sujet est que strictement mathématique parlant de "l'égalité", défini par la java de la méthode equals n'est pas une égalité, mais plutôt le plus général de la relation d'équivalence http://en.wikipedia.org/wiki/Equivalence_relation parce que les différents objets peuvent également être "égaux" en fonction de java, contredisant ainsi la en oeuvre l'antisymétrie de la propriété nécessaire pour une véritable égalité.

Conclusion:

.est égal à Java est une relation d'équivalence (qui nécessite par transitivité)

== en Java est une égalité (ou l'identité) rapport

1voto

Considérons l'objet a == b == c avec a! = C (égalité non transitive)

Le premier problème serait le contrat hashcode () qui requiert que les codes de hachage soient égaux si les objets sont égaux. Et vous pourrez ajouter a et c au même ensemble - cela peut entraîner des problèmes subtils dans des endroits inattendus

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X