当我们比较单个Collection
对象中的元素时,我们是否总是需要覆盖equals
方法?如果是的话我们为什么要这样做。
实际上,我们通过CompareTo
方法将元素与1,0,-1
整数作为返回类型进行比较。
答案 0 :(得分:2)
如果使用集合,Java将使用equals()
方法来比较对象。如果您使用的是已排序的集合,则必须实现Comparable
接口。
默认情况下,如果两个对象实例相同,equals()
将为true,如果要在比较中实现更多逻辑,则必须实现给定方法。
答案 1 :(得分:1)
如果你没有覆盖你的类中的equals方法,那么将调用超类'(通常是java.lang.Object
)方法。如果这是你想要的,那么你不需要覆盖equals
。
现在,Object.equals()
does可能不是您想要的:
类Object的equals方法实现最具辨别力 对象可能的等价关系;也就是说,对于任何非null 引用值x和y,当且仅当x时,此方法返回true 和y引用相同的对象(x == y的值为true)。
例如,Integer
会覆盖equals方法,因此可以:
Integer a = new Integer(3);
Integer b = new Integer(3);
assert(a.equals(b)); //Succeeds
如果没有,则a不等于b(根据Object.equals)。所以,这取决于你需要做什么。大多数Java标准类已经有一个正确的equals方法,你不需要覆盖它。但是,您定制的类将默认为Object.equals(),它将检查对象是否是同一个对象(相同的实例,内存中的同一串字节),这通常不是您想要的。
另外,请注意HashMap不会使用equals进行比较,而是使用hashCode,例如,TreeSet将使用Comparable
接口方法。通常,如果您覆盖 equals ,请不要忘记同时覆盖 hashCode (如果您愿意,Eclipse具有良好的自动生成选项)。
答案 2 :(得分:1)
需要重写equals方法,以便进行更复杂的比较,然后仅检查两个实例是否相同。
假设您有一个类Person,并且您希望具有相同社会安全号码的人员彼此“相等”。然后一个简单的实现可能如下所示:
public boolean equals(Object obj) {
if (this.getSocialSecurityNumber() == obj.getSocialSecurityNumber())
return true;
else
return false;
}
这会导致每个Person对象“相等”,因为它们具有相同的socialsecuritynumber。请注意,除非您需要特定的行为,否则覆盖equals不是nessecary,如此示例
答案 3 :(得分:1)
当我们比较单个Collection Object中的元素时,我们总是需要覆盖equals方法吗?
没有。在一般情况下,您不必覆盖equals(Object)
。对于您的特定应用程序,可能适当/必要覆盖equals(和hashcode),但这取决于方法的非重写版本以及应用程序需要的行为。
实际上我们通过CompareTo方法将元素与整数形式进行比较,为1,0,-1及其返回类型。
如果您使用的是使用compareTo
或compare
而不是equals
的Collection类,那么您显然不会必须覆盖{{1 }}。但是,类equals
和equals
方法保持一致是一种很好的做法。未来的开发人员可能会认为他们是一致的,并且当他们不是时,会得到令人讨厌的惊喜(当然,可能存在不一致的实际原因......但是你不应该因为懒惰而让这些方法不一致。)
答案 4 :(得分:1)
好吧,如果你已经实现了compareTo()方法,那么你不再需要实现equals(),因为compareTo()本身会检查相等性。
即使你单独实现了equals(),compareTo()也会隐藏它的实现,你的对象将永远不会针对equals()方法进行测试。
答案 5 :(得分:0)
是。我们总是需要覆盖equals方法。
例如如果您要在集合中添加 null ,我们无法使用 compareTo ,因为它会抛出 NullPointerException < / strong>即可。但是,equals()不会抛出 NullPointerException 。
覆盖equals()以避免NullPointerException更安全。
答案 6 :(得分:0)
我想你正在谈论Comparable
接口哪个实现强烈建议与对象的equals()
方法保持一致,但仍然不需要。
Comparable description