重写equals和hashCode时必须考虑哪些问题/陷阱?
当前回答
逻辑上我们有:
a.getClass().equals(b.getClass()) && a.equals(b) ⇒ a.hashCode() == b.hashCode()
但反之亦然!
其他回答
对于继承友好的实现,请查看Tal Cohen的解决方案,如何正确地实现equals()方法?
简介:
在《有效Java编程语言指南》(Addison-Wesley, 2001)一书中,Joshua Bloch声称“根本没有办法扩展可实例化类并在保留等于契约的同时添加一个方面。”塔尔不同意。
他的解决方案是通过调用另一个非对称的blindlyEquals()来实现equals()。blindlyEquals()被子类覆盖,equals()被继承,并且永远不会被覆盖。
例子:
class Point {
private int x;
private int y;
protected boolean blindlyEquals(Object o) {
if (!(o instanceof Point))
return false;
Point p = (Point)o;
return (p.x == this.x && p.y == this.y);
}
public boolean equals(Object o) {
return (this.blindlyEquals(o) && o.blindlyEquals(this));
}
}
class ColorPoint extends Point {
private Color c;
protected boolean blindlyEquals(Object o) {
if (!(o instanceof ColorPoint))
return false;
ColorPoint cp = (ColorPoint)o;
return (super.blindlyEquals(cp) &&
cp.color == this.color);
}
}
注意,如果要满足利斯科夫替换原则,equals()必须跨继承层次结构工作。
仍然令人惊讶的是,没有人推荐番石榴库。
//Sample taken from a current working project of mine just to illustrate the idea
@Override
public int hashCode(){
return Objects.hashCode(this.getDate(), this.datePattern);
}
@Override
public boolean equals(Object obj){
if ( ! obj instanceof DateAndPattern ) {
return false;
}
return Objects.equal(((DateAndPattern)obj).getDate(), this.getDate())
&& Objects.equal(((DateAndPattern)obj).getDate(), this.getDatePattern());
}
在检查成员是否相等之前,有几种方法可以检查类是否相等,我认为这两种方法在适当的情况下都是有用的。
使用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;
}
}
对于平等的人,可以看看Angelika Langer的《平等的秘密》。我非常喜欢它。她还提供了关于Java泛型的常见问题解答。在这里查看她的其他文章(向下滚动到“核心Java”),在那里她还继续介绍了第2部分和“混合类型比较”。祝你阅读愉快!
关于obj.getClass() != getClass()的澄清。
此语句是equals()不友好继承的结果。JLS (Java语言规范)指定如果A.equals(B) == true,那么B.equals(A)也必须返回true。如果省略该语句,继承重写equals()(并改变其行为)的类将破坏此规范。
考虑下面的例子,当语句被省略时会发生什么:
class A {
int field1;
A(int field1) {
this.field1 = field1;
}
public boolean equals(Object other) {
return (other != null && other instanceof A && ((A) other).field1 == field1);
}
}
class B extends A {
int field2;
B(int field1, int field2) {
super(field1);
this.field2 = field2;
}
public boolean equals(Object other) {
return (other != null && other instanceof B && ((B)other).field2 == field2 && super.equals(other));
}
}
做新A(1)= (new A(1))同样,new B(1,1)。equals(new B(1,1))结果给出true,就像它应该的那样。
这看起来很好,但是看看如果我们尝试使用这两个类会发生什么:
A a = new A(1);
B b = new B(1,1);
a.equals(b) == true;
b.equals(a) == false;
显然,这是错误的。
如果你想确保对称条件。如果b=a,则a=b,而利斯科夫替换原理不仅在b实例中调用super.equals(other),而且在a实例中检查:
if (other instanceof B )
return (other != null && ((B)other).field2 == field2 && super.equals(other));
if (other instanceof A) return super.equals(other);
else return false;
它将输出:
a.equals(b) == true;
b.equals(a) == true;
其中,如果a不是B的引用,那么它可能是类a的引用(因为您扩展了它),在这种情况下,也可以调用super.equals()。
推荐文章
- 在流中使用Java 8 foreach循环移动到下一项
- 访问限制:'Application'类型不是API(必需库rt.jar的限制)
- 用Java计算两个日期之间的天数
- 如何配置slf4j-simple
- 在Jar文件中运行类
- 带参数的可运行?
- 我如何得到一个字符串的前n个字符而不检查大小或出界?
- 我可以在Java中设置enum起始值吗?
- Java中的回调函数
- c#和Java中的泛型有什么不同?和模板在c++ ?
- 在Java中,流相对于循环的优势是什么?
- Jersey在未找到InjectionManagerFactory时停止工作
- 在Java流是peek真的只是调试?
- Recyclerview不调用onCreateViewHolder
- 将JSON字符串转换为HashMap