|
ap或其它基于散列的集合中使用Integer作为关键字的话，什么也不会发生。但是，如果我们在HashMap中使用这类Integer对象作为关键字，我们将不能够可靠地检索相关的值，除非我们在get()调用中使用与put()调用中极其类似的Integer实例。这要求确保在我们的整个程序中，只能使用对应于特定整数值的Integer对象的一个实例。不用说，这种方法极不方便而且错误频频。
Object的interface contract要求如果根据 equals()两个对象是相等的，那么它们必须有相同的hashCode()值。当其识别能力整个包含在equals()中时，为什么我们的根对象类需要hashCode()？hashCode()方法纯粹用于提高效率。Java平台设计人员预计到了典型Java应用程序中基于散列的集合类（Collection Class)的重要性--如Hashtable、HashMap和HashSet，并且使用equals()与许多对象进行比较在计算方面非常昂贵。使所有Java对象都能够支持 hashCode()并结合使用基于散列的集合，可以实现有效的存储和检索。
实施equals()和hashCode()的需求
实施equals()和 hashCode()有一些限制，Object文件中列举出了这些限制。特别是equals()方法必须显示以下属性：
Symmetry：两个引用，a和 b,a.equals(b) if and only if b.equals(a)
Reflexivity：所有非空引用， a.equals(a)
Transitivity：If a.equals(b) and b.equals(c), then a.equals(c)
Consistency with hashCode()：两个相等的对象必须有相同的hashCode()值
Object的规范中并没有明确要求equals()和 hashCode() 必须一致 -- 它们的结果在随后的调用中将是相同的，假设“不改变对象相等性比较中使用的任何信息。”这听起来象“计算的结果将不改变，除非实际情况如此。”这一模糊声明通常解释为相等性和散列值计算应是对象的可确定性功能，而不是其它。
对象相等性意味着什么？
人们很容易满足Object类规范对equals() 和 hashCode() 的要求。决定是否和如何忽略equals()除了判断以外，还要求其它。在简单的不可修值类中，如Integer(事实上是几乎所有不可修改的类)，选择相当明显 -- 相等性应基于基本对象状态的相等性。在Integer情况下，对象的唯一状态是基本的整数值。
对于可修改对象来说，答案并不总是如此清楚。equals() 和hashCode() 是否应基于对象的标识(象缺省实施)或对象的状态(象Integer和String)？没有简单的答案 -- 它取决于类的计划使用。对于象List和Map这样的容器来说，人们对此争论不已。Java类库中的大多数类，包括容器类，错误出现在根据对象状态来提供equals()和hashCode()实施。
如果对象的hashCode()值可以基于其状态进行更改，那么当使用这类对象作为基于散列的集合中的关键字时我们必须注意，确保当它们用于作为散列关键字时，我们并不允许更改它们的状态。所有基于散列的集合假设，当对象的散列值用于作为集合中的关键字时它不会改变。如果当关键字在集合中时它的散列代码被更改，那么将产生一些不可预测和容易混淆的结果。实践过程中这通常不是问题 -- 我们并不经常使用象List这样的可修改对象做为HashMap中的关键字。
一个简单的可修改类的例子是Point，它根据状态来定义equals()和hashCode()。如果两个Point 对象引用相同的(x, y)座标，Point的散列值来源于x和y座标值的IEEE 754-bit表示，那么它们是上一页 [1] [2] [3] [4] 下一页 |
|
|
|
|
|
|
|
