While I think it is generally a good idea to avoid basing equality on associations, I would argue that this does not apply in all cases. While it is a good rule of thumb, there are likely a number of cases where this rule breaks completely.
It is entirely dependent on the domain and what it means for two objects to be equal. For example:
If you have a cohort of students, taught by a teacher, you could determine equality by requiring that another cohort must contain the same students be (pair-wise equal) and be taught by the same teacher. In that case, the cohort's equality is strictly dependent on each of it's pieces being equal.
检查关联会引入实际问题。存在双向关联的危险（配偶-of，例如）导致无限循环。间接关联会影响性能，需要检查工作集中的所有对象：如果您的 Person 对象具有 parent-of 和 child-of< /em> 关联，Person.equals() 实际上会告诉您家谱树是否等价。
Equality should not depend in any way on associated objects, therefore equals() should not examine associates. It should not even depend on the identity of associates, or even whether an object has an association. I'm surprised that this advice is not explicitly stated often enough for me to have found it.
From an object modelling point of view, it is natural to consider two things with different associations to be equivalent. If a mad scientist were to create an exact duplicate of me, we would say the doppelgänger and I were "the same" (equivalent), even though we had different fathers (different fathered-by associations). The doppelgänger might not even have a father (if the scientist were more mad physicist than mad biologist).
Examining associations introduces practical problems. There is the danger of bi-directional associations (spouse-of, for example) causing infinite loops. There is the performance hit of indirect associations requiring examination of potentially all objects in the working-set: if your Person objects have parent-of and child-of associations, Person.equals() would actually tell you whether family trees were equivalent.
Short answer: make equals() do what you need it to do. But be careful.
Where the class may be used as a key in a HashMap (or stored in a HashSet), equals() must be constant for the time that it's in the map. This suggests that, in order to avoid a lot of analysis and/or bugs, classes used as HashMap keys should restrict equals() to effectively immutable fields - including associations.
You also must ensure that any equals-included associated object has a similarly immutable-for-contained-scope equals() implementation, and doesn't do an equals() back on the original object, causing runaway recursion.
发布评论
评论（4）
虽然我认为避免将平等建立在关联上通常是一个好主意，但我认为这并不适用于所有情况。虽然这是一个很好的经验法则，但在很多情况下，这条规则可能会被完全打破。
它完全取决于域以及两个对象相等的含义。例如：
如果您有一群学生，由一位老师授课，您可以通过要求另一个班级必须包含相同的学生（两两相等）并由同一位老师授课来确定平等。在这种情况下，队列的平等严格取决于每个部分的平等。
While I think it is generally a good idea to avoid basing equality on associations, I would argue that this does not apply in all cases. While it is a good rule of thumb, there are likely a number of cases where this rule breaks completely.
It is entirely dependent on the domain and what it means for two objects to be equal. For example:
If you have a cohort of students, taught by a teacher, you could determine equality by requiring that another cohort must contain the same students be (pair-wise equal) and be taught by the same teacher. In that case, the cohort's equality is strictly dependent on each of it's pieces being equal.
平等不应以任何方式依赖于关联对象，因此
equals()不应检查关联对象。它甚至不应该依赖于关联者的身份，甚至不应该依赖于对象是否具有关联。令我惊讶的是，这个建议并没有被明确地多次提及，以至于我无法找到它。从对象建模的角度来看，很自然地认为两个具有不同关联的事物是等效的。如果一个疯狂的科学家要创造出我的一模一样的复制品，我们会说分身和我是“相同的”（等价），即使我们有不同的父亲（不同的父亲协会）。这个分身甚至可能没有父亲（如果科学家是疯狂的物理学家而不是疯狂的生物学家）。
检查关联会引入实际问题。存在双向关联的危险（配偶-of，例如）导致无限循环。间接关联会影响性能，需要检查工作集中的所有对象：如果您的
Person对象具有 parent-of 和 child-of< /em> 关联，Person.equals()实际上会告诉您家谱树是否等价。Equality should not depend in any way on associated objects, therefore
equals()should not examine associates. It should not even depend on the identity of associates, or even whether an object has an association. I'm surprised that this advice is not explicitly stated often enough for me to have found it.From an object modelling point of view, it is natural to consider two things with different associations to be equivalent. If a mad scientist were to create an exact duplicate of me, we would say the doppelgänger and I were "the same" (equivalent), even though we had different fathers (different fathered-by associations). The doppelgänger might not even have a father (if the scientist were more mad physicist than mad biologist).
Examining associations introduces practical problems. There is the danger of bi-directional associations (spouse-of, for example) causing infinite loops. There is the performance hit of indirect associations requiring examination of potentially all objects in the working-set: if your
Personobjects have parent-of and child-of associations,Person.equals()would actually tell you whether family trees were equivalent.一般来说也许不是。但是如果一辆汽车有车架、车身、发动机、车轮等，我们可以考虑不同的 equals 实现。
in general perhaps not. but how about a car that has frame, body, engine, wheels etc. one could consider different implementations of equals.
简短的回答：让 equals() 做你需要它做的事情。但要小心。
如果类可以用作
HashMap中的键（或存储在HashSet中），则 equals() 在其位于映射中时必须保持不变。这表明，为了避免大量分析和/或错误，用作 HashMap 键的类应该将 equals() 限制为有效的不可变字段 - 包括关联。您还必须确保任何包含 equals 的关联对象具有类似的不可变的包含范围 equals() 实现，并且不会对原始对象执行 equals() 操作，从而导致失控递归。
Short answer: make equals() do what you need it to do. But be careful.
Where the class may be used as a key in a
HashMap(or stored in aHashSet), equals() must be constant for the time that it's in the map. This suggests that, in order to avoid a lot of analysis and/or bugs, classes used as HashMap keys should restrictequals()to effectively immutable fields - including associations.You also must ensure that any equals-included associated object has a similarly immutable-for-contained-scope equals() implementation, and doesn't do an equals() back on the original object, causing runaway recursion.