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

我发现的一个问题是两个对象包含彼此的引用(一个例子是父/子关系，在父对象上有一个方便的方法来获取所有的子对象)。 例如，在执行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

玩得开心!@ .@

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

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

如果您正在使用对象关系映射器(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()中不变的属性子集