4.1.6 实现equals()和hashCode()

 

在java中，equals()方法通常被应用程序调用或者被集合调用。例如，Set会调用equals()方法来确定元素是否重复。

首先，我们来考虑equals()的默认实现。Hibernate保证在每个Session中，每个表格行有且只有一个对象与其对应。如果你没有从其他的Session中取得对象的话，那么默认的equals方法应该是有效的。一旦你拥有被多个Session共享的对象的话，那么在一个Set中就可能存在多个对象对应同一行数据的情况。这在语义上明显是错误的。当然，如果你经验丰富的话，可以构建一个复杂的程序来保证多个Session使用detached对象的正确性。这么做的好处就是你无需再另外实现equals()方法了。

当然，如果这种相等的概念不是你想要的，那么你就需要重写equals()方法了。请记住当你重写equals()方法的时候，记得也要重写hashCode()方法。让我们来看看一些重写equals()和hashCode()的方法。

使用数据库标识符

一种聪明的做法就是比较数据库的标识符来实现equals()方法：

请注意当对象编程transient实例的时候，equals方法如何变化，因为在transient状态下，数据库标识符仍未进行分配。

不幸的是，这种方法与一个巨大的缺陷：直到一个实体被保存的时候Hibernate才会分配数据库标识符。因此，如果一个对象在未保存之前就被加入到了Set，那么加入到Set的时候其Hashcode会发生变化。这回导致饿cascade保存。我们不建议使用这种方法来判断相等性。

值比较

一种更好的做法除了数据库标识符属性，在equals方法包含所有属性的比较。这是大部分人认为的equals方法，我们称之为的值比较。

当我们说所有属性的时候，其实并不包括集合。集合一般对应着另外一个表，因此包含它是错误的。更重要的是，你不会想要所有的对象都去执行equals()方法的。在User的例子中，这就意味着你不能包含items集合。因此，下面的实现是你可能用到的：

然而，这种方法仍然存在两个问题：

1)在不同Session中的对象可能不相等，如果其中的一个被修改了的话

2)对应不同数据库实体的实例可能被认为是相等的，除非有能够保证属性唯一的方法。

为了找到解决办法，你需要明白业务主键的意义。

业务主键

首先它是一个属性或者是多个属性的组合，对于同一个数据库实体来说它是唯一的。与数据库主键不同，它可以改变，只要不经常改变就可以了。

我们建议每个实体都需要一个业务主键，就算它包含对象中的所有属性。

业务主键的比较说明了equals方法仅仅需要比较那些需要比较的属性。这看起来是一个完美的解决方案。唯一的缺点就是需要仔细考虑来决定哪些属性来做为业务主键。

对于User类来说，username是一个候选的业务主键。它不能为null，并且唯一，而且很少改动。

对于一些其他的类，业务主键可能变得更加复杂，它可能有许多属性组合而成。例如，Bid类的业务主键可能是item ID的总和，或者再加上日期以及时间。

你可能会注意到equals()以及hashCode()方法经常会通过getter方法来访问属性。这很重要，因为其他对象可能是一个代理对象，并不一定会真的维持一个持久状态。这是Hibernate中不透明的一点，但是通过getter方法来访问对象确实是一个更好的办法。

最后，注意当需要修改业务主键的时候，要格外小心；不要修改那些在Set中的领域模型。