重写equals和hashCode时必须考虑哪些问题/陷阱?


当前回答

关于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()。

其他回答

理论(适用于语言律师和数学爱好者):

Equals () (javadoc)必须定义等价关系(它必须是自反的、对称的和可传递的)。此外,它必须是一致的(如果对象没有被修改,那么它必须一直返回相同的值)。此外,o.equals(null)必须总是返回false。

hashCode() (javadoc)也必须是一致的(如果对象没有按照equals()进行修改,它必须一直返回相同的值)。

这两种方法的关系是:

当a. = (b)时,则a.hashCode()必须与b. hashcode()相同。

在实践中:

如果你覆盖了一个,那么你也应该覆盖另一个。

使用用于计算equals()的相同字段集来计算hashCode()。

使用Apache Commons Lang库中的优秀辅助类EqualsBuilder和HashCodeBuilder。一个例子:

public class Person {
    private String name;
    private int age;
    // ...

    @Override
    public int hashCode() {
        return new HashCodeBuilder(17, 31). // two randomly chosen prime numbers
            // if deriving: appendSuper(super.hashCode()).
            append(name).
            append(age).
            toHashCode();
    }

    @Override
    public boolean equals(Object obj) {
       if (!(obj instanceof Person))
            return false;
        if (obj == this)
            return true;

        Person rhs = (Person) obj;
        return new EqualsBuilder().
            // if deriving: appendSuper(super.equals(obj)).
            append(name, rhs.name).
            append(age, rhs.age).
            isEquals();
    }
}

还记得:

当使用基于哈希的集合或映射(如HashSet、LinkedHashSet、HashMap、Hashtable或WeakHashMap)时,确保你放入集合中的关键对象的hashCode()在对象在集合中时永远不会改变。确保这一点的防弹方法是使您的密钥不可变,这还有其他好处。

对于平等的人,可以看看Angelika Langer的《平等的秘密》。我非常喜欢它。她还提供了关于Java泛型的常见问题解答。在这里查看她的其他文章(向下滚动到“核心Java”),在那里她还继续介绍了第2部分和“混合类型比较”。祝你阅读愉快!

对于继承友好的实现,请查看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()必须跨继承层次结构工作。

关于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()。

在检查成员是否相等之前,有几种方法可以检查类是否相等,我认为这两种方法在适当的情况下都是有用的。

使用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;
  }

}