重写equals和hashCode时必须考虑哪些问题/陷阱?
当前回答
在检查成员是否相等之前,有几种方法可以检查类是否相等,我认为这两种方法在适当的情况下都是有用的。
使用instanceof操作符。 使用this.getClass () .equals (that.getClass())。
我在最终的等号实现中使用#1,或者在实现指定等号算法的接口时使用#1。util集合接口-检查with (obj instanceof Set)或任何你正在实现的接口的正确方法)。当等号可以被重写时,这通常是一个糟糕的选择,因为这会破坏对称性。
选项#2允许安全地扩展类,而不重写等号或破坏对称性。
如果你的类也是Comparable类,equals和compareTo方法也应该是一致的。下面是Comparable类中equals方法的模板:
final class MyClass implements Comparable<MyClass>
{
…
@Override
public boolean equals(Object obj)
{
/* If compareTo and equals aren't final, we should check with getClass instead. */
if (!(obj instanceof MyClass))
return false;
return compareTo((MyClass) obj) == 0;
}
}
其他回答
如果您正在使用对象关系映射器(Object-Relationship Mapper, ORM)(如Hibernate)处理持久化的类,如果您不认为这已经不合理地复杂,那么有一些问题值得注意!
惰性加载对象是子类
如果您的对象是使用ORM持久化的,那么在许多情况下,您将使用动态代理来避免过早地从数据存储中加载对象。这些代理被实现为您自己类的子类。这意味着This . getclass () == o.getClass()将返回false。例如:
Person saved = new Person("John Doe");
Long key = dao.save(saved);
dao.flush();
Person retrieved = dao.retrieve(key);
saved.getClass().equals(retrieved.getClass()); // Will return false if Person is loaded lazy
如果您正在处理ORM,使用o instanceof Person是唯一能够正确运行的方法。
惰性加载对象具有空字段
orm通常使用getter强制加载惰性加载的对象。这意味着如果person被惰性加载,person.name将为空,即使person. getname()强制加载并返回“John Doe”。根据我的经验,这种情况在hashCode()和equals()中更常见。
如果您正在处理ORM,请确保始终使用getter,并且永远不要在hashCode()和equals()中使用字段引用。
保存一个对象会改变它的状态
持久对象通常使用id字段保存对象的键。当对象第一次保存时,该字段将自动更新。不要在hashCode()中使用id字段。但是你可以在equals()中使用它。
我经常使用的一个模式是
if (this.getId() == null) {
return this == other;
}
else {
return this.getId().equals(other.getId());
}
但是:你不能在hashCode()中包含getId()。如果这样做,当对象被持久化时,它的hashCode将发生变化。如果对象在HashSet中,您将“永远”找不到它。
在我的Person示例中,我可能会使用getName()来表示hashCode, getId()加上getName()(只是为了偏执)来表示equals()。对于hashCode()来说,如果存在一些“冲突”风险是可以的,但对于equals()来说就绝对不行。
hashCode()应该使用equals()中不变的属性子集
我发现的一个问题是两个对象包含彼此的引用(一个例子是父/子关系,在父对象上有一个方便的方法来获取所有的子对象)。 例如,在执行Hibernate映射时,这类事情相当常见。
如果在hashCode或equals测试中包含关系的两端,则有可能进入以StackOverflowException结束的递归循环。 最简单的解决方案是在方法中不包括getChildren集合。
超类中有两个方法,如java.lang.Object。我们需要将它们重写为自定义对象。
public boolean equals(Object obj)
public int hashCode()
相等的对象只要相等就必须产生相同的哈希码,然而不相等的对象不需要产生不同的哈希码。
public class Test
{
private int num;
private String data;
public boolean equals(Object obj)
{
if(this == obj)
return true;
if((obj == null) || (obj.getClass() != this.getClass()))
return false;
// object must be Test at this point
Test test = (Test)obj;
return num == test.num &&
(data == test.data || (data != null && data.equals(test.data)));
}
public int hashCode()
{
int hash = 7;
hash = 31 * hash + num;
hash = 31 * hash + (null == data ? 0 : data.hashCode());
return hash;
}
// other methods
}
如果你想了解更多,请点击这个链接http://www.javaranch.com/journal/2002/10/equalhash.html
这是另一个例子, http://java67.blogspot.com/2013/04/example-of-overriding-equals-hashcode-compareTo-java-method.html
玩得开心!@ .@
对于平等的人,可以看看Angelika Langer的《平等的秘密》。我非常喜欢它。她还提供了关于Java泛型的常见问题解答。在这里查看她的其他文章(向下滚动到“核心Java”),在那里她还继续介绍了第2部分和“混合类型比较”。祝你阅读愉快!
在检查成员是否相等之前,有几种方法可以检查类是否相等,我认为这两种方法在适当的情况下都是有用的。
使用instanceof操作符。 使用this.getClass () .equals (that.getClass())。
我在最终的等号实现中使用#1,或者在实现指定等号算法的接口时使用#1。util集合接口-检查with (obj instanceof Set)或任何你正在实现的接口的正确方法)。当等号可以被重写时,这通常是一个糟糕的选择,因为这会破坏对称性。
选项#2允许安全地扩展类,而不重写等号或破坏对称性。
如果你的类也是Comparable类,equals和compareTo方法也应该是一致的。下面是Comparable类中equals方法的模板:
final class MyClass implements Comparable<MyClass>
{
…
@Override
public boolean equals(Object obj)
{
/* If compareTo and equals aren't final, we should check with getClass instead. */
if (!(obj instanceof MyClass))
return false;
return compareTo((MyClass) obj) == 0;
}
}
推荐文章
- 如何格式化Joda-Time DateTime仅为mm/dd/yyyy?
- 如何在POM.xml中引用环境变量?
- 如何在android中复制一个文件?
- 将整数转换为字符串,以逗号表示千
- 接口方法的最终参数-有什么意义?
- Java中的@UniqueConstraint注释
- 如何在清洁模式下运行eclipse ?如果我们这样做会发生什么?
- JavaScript: override alert()
- 获取java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory异常
- Java中的正则表达式命名组
- c#和Java的主要区别是什么?
- 什么是NullPointerException,我如何修复它?
- 在Java中使用“final”修饰符
- 无法在Flutter上找到捆绑的Java版本
- 如何在Kotlin解析JSON ?