【软件构造】第三章第五节 ADT和OOP中的等价性

第三章第五节 ADT和OOP中的等价性

在很多场景下，需要判定两个对象是否 “相等”，例如：判断某个Collection 中是否包含特定元素。 
==和equals()有和区别？如何为自定义 ADT正确实现equals()？

OutLine

• 等价性equals() 和 ==
• equals()的判断方法
  • 自反、传递、对称性
• hashCode()
• 不可变类型的等价性
• 可变类型的等价性
  • 观察等价性
  • 行为等价性

Notes

##  等价性equals() 和 ==

• 和很多其他语言一样，Java有两种判断相等的操作—— == 和 equals() 。
• ==是引用等价性 ；而equals()是对象等价性。 
  • == 比较的是索引。更准确的说，它测试的是指向相等（referential equality）。如果两个索引指向同一块存储区域，那它们就是==的。对于我们之前提到过的快照图来说，==就意味着它们的箭头指向同一个对象。
  • equals()操作比较的是对象的内容，换句话说，它测试的是对象值相等（object equality）。e在每一个ADT中，quals操作必须合理定义。

Java中的数据类型，可分为两类：

• 基本数据类型，也称原始数据类型。byte,short,char,int,long,float,double,boolean
  • 他们之间的比较，应用双等号（==）,比较的是他们的值。
• 复合数据类型(类) 
  • 当他们用（==）进行比较的时候，比较的是他们在内存中的存放地址，所以，除非是同一个new出来的对象，他们的比较后的结果为true，否则比较后结果为false。
  • JAVA当中所有的类都是继承于Object这个基类的，在Object中的基类中定义了一个equals的方法，这个方法的初始行为是比较对象的内存地址，但在一些类库当中这个方法被覆盖掉了，如String,Integer,Date在这些类当中equals有其自身的实现，而不再是比较类在堆内存中的存放地址了。
  • 对于复合数据类型之间进行equals比较，在没有覆写equals方法的情况下，他们之间的比较还是基于他们在内存中的存放位置的地址值的，因为Object的equals方法也是用双等号（==）进行比较的，所以比较后的结果跟双等号（==）的结果相同。
    

 关于equals()与== 欢迎阅读 海子的博客

## equals()的判断方法

严格来说，我们可以从三个角度定义相等：

• 抽象函数：回忆一下抽象函数（AF: R → A ），它将具体的表示数据映射到了抽象的值。如果AF(a)=AF(b)，我们就说a和b相等。
• 等价关系：等价是指对于关系E ⊆ T x T ，它满足：
  • 自反性: x.equals(x)必须返回true
  • 对称性: x.equals(y)与y.equals(x)的返回值必须相等。
  • 传递性: x.equals(y)为true，y.equals(z)也为true，那么x.equals(z)必须为true。

以上两种角度/定义实际上是一样的，通过等价关系我们可以构建一个抽象函数（译者注：就是一个封闭的二元关系运算）；而抽象函数也能推出一个等价关系。

• 从使用者/外部的角度去观察：我们说两个对象相等，当且仅当使用者无法观察到它们之间有不同，即每一个观察总会都会得到相同的结果。例如对于两个集合对象 {1,2} 和 {2,1}，我们就无法观察到不同：
  • |{1,2}| = 2, |{2,1}| = 2
  • 1 ∈ {1,2} is true, 1 ∈ {2,1} is true
  • 2 ∈ {1,2} is true, 2 ∈ {2,1} is true
  • 3 ∈ {1,2} is false, 3 ∈ {2,1} is false
  • …

## hashCode()方法

• 对于不可变类型：
  • equals() 应该比较抽象值是否相等。这和 equals() 比较行为相等性是一样的。
  • hashCode() 应该将抽象值映射为整数。
  • 所以不可变类型应该同时覆盖 equals() 和 hashCode().
• 对于可变类型：
  • equals() 应该比较索引，就像 ==一样。同样的，这也是比较行为相等性。
  • hashCode() 应该将索引映射为整数。
  • 所以可变类型不应该将 equals() 和 hashCode() 覆盖，而是直接继承 Object中的方法。Java没有为大多数聚合类遵守这一规定，这也许会导致上面看到的隐秘bug。
• equals与hashCode两个方法均属于Object对象，equals根据我们的需要重写， 用来判断是否是同一个内容或同一个对象，具体是判断什么，怎么判断得看怎么重写，默认的equals是比较地址。
• hashCode方法返回一个int的哈希码， 同样可以重写来自定义获取哈希码的方法。
• equals判定为相同， hashCode一定相同。equals判定为不同，hashCode不一定不同。
• hashCode必须为两个被该equals方法视为相等的对象产生相同的结果。
• 与equals()方法类似，hashCode()方法可以被重写。JDK中对hashCode()方法的作用，以及实现时的注意事项做了说明：
  • hashCode()在哈希表中起作用，如java.util.HashMap。
  • 如果对象在equals()中使用的信息都没有改变，那么hashCode()值始终不变。
  • 如果两个对象使用equals()方法判断为相等，则hashCode()方法也应该相等。
  • 如果两个对象使用equals()方法判断为不相等，则不要求hashCode()也必须不相等；但是开发人员应该认识到，不相等的对象产生不相同的hashCode可以提高哈希表的性能。

## 不可变类型的等价性

首先来看Object中实现的缺省equals():

public class Object {
    ...
    public boolean equals(Object that) {
        return this == that;
    }
}

在Object中实现的缺省equals()是在判断引用等价性。这通常不是程序员所期望的，因此需要重写，下面是一个栗子：

public class Duration {
    ...
    // Problematic definition of equals()
    public boolean equals(Duration that) {
        return this.getLength() == that.getLength();
    }
}

尝试如下客户端代码，可得到

Duration d1 = new Duration (1, 2);
Duration d2 = new Duration (1, 2);
Object o2 = d2;
d1.equals(d2) → true
d1.equals(o2) → false

基于以上结果进行以下解释：

• 即使d2和o2最终参照相同的对象在内存中，对他们来说你仍然得到不同的结果。
• 事实证明，该方法Duration已经超载equals()，因为方法签名与Object’s 不相同。我们实际上有两种equals()方法：隐式equals(Object)继承Object，和新的equals(Duration)。
• 如果我们通过一个Object参考，那么d1.equals(o2)我们最终会调用equals(Object)实现。
• 如果我们通过Duration参考，如在d1.equals(d2)，我们最终调用equals(Duration)版本。
• 即使发生这种情况o2，d2两者都会在运行时指向同一个对象！平等已经变得不一致。

我们需要注释 @Override ，重写超类中的方法，因此，这里实施正确的 equals() 方法：

@Override
public boolean equals (Object thatObject) {
    if (!(thatObject instanceof Duration)) return false;
    Duration thatDuration = (Duration) thatObject;
    return this.getLength() == thatDuration.getLength();
}

再次执行客户端代码，可得到：

Duration d1 = new Duration(1, 2);
Duration d2 = new Duration(1, 2);
Object o2 = d2;
d1.equals(d2) → true
d1.equals(o2) → true

## 可变类型的等价性

　　回忆之前我们对于相等的定义，即它们不能被使用者观察出来不同。而对于可变对象来说，它们多了一种新的可能：通过在观察前调用改造者，我们可以改变其内部的状态，从而观察出不同的结果。

• 所以我们重新定义两种相等：
  • 观察等价性：两个索引在不改变各自对象状态的前提下不能被区分。即通过只调用observer，producer和creator的方法，它测试的是这两个索引在当前程序状态下“看起来”相等。
  • 行为等价性：两个索引在任何代码的情况下都不能被区分，即使有一个对象调用了改造者。它测试的是两个对象是否会在未来所有的状态下“行为”相等。

• 对于不可变对象，观察相等和行为相等是完全等价的，因为它们没有改造者改变对象内部的状态。
• 对于可变对象，Java通常实现的是观察相等。例如两个不同的 List 对象包含相同的序列元素，那么equals() 操作就会返回真。

在有些时候，观察等价性可能导致bug，甚至可能破坏RI。

假设我们做了一个List，然后把它放到Set：

List<String> list = new ArrayList<>();
list.add("a");

Set<List<String>> set = new HashSet<List<String>>();
set.add(list);

我们可以检查该集合是否包含我们放入其中的列表，并且它会：

set.contains(list) → true

但是如果我们修改这个存入的列表：

list.add("goodbye");

它似乎就不在集合中了！

set.contains(list) → false!

事实上，更糟糕的是：当我们（用迭代器）循环遍历这个集合时，我们依然会发现集合存在，但是contains() 还是说它不存在！

for (List<String> l : set) {
    set.contains(l) → false!
}

　　如果一个集合的迭代器和contains()都互相冲突的时候，显然这个集合已经被破坏了。

　　发生了什么？我们知道 List<String> 是一个可变对象，而在Java对可变对象的实现中，改造操作通常都会影响 equals() 和 hashCode()的结果。所以列表第一次放入 HashSet的时候，它是存储在这时 hashCode() 对应的索引位置。但是后来列表发生了改变，计算 hashCode() 会得到不一样的结果，但是 HashSet 对此并不知道，所以我们调用contains时候就会找不到列表。

　　当 equals() 和 hashCode() 被改动影响的时候，我们就破坏了哈希表利用对象作为键的不变量。

下面是 java.util.Set规格说明中的一段话：

注意：当可变对象作为集合的元素时要特别小心。如果对象内容改变后会影响相等比较而且对象是集合的元素，那么集合的行为是不确定的。　

　　我们应该从这个例子中吸取教训，对可变类型，实现行为等价性即可，也就是说，只有指 向同样内存空间的objects，才是相等的。所以对可变类型来说，无需重写这两个函数，直接继承 Object对象的两个方法即可。 如果一定要判断两个可变对象看起来是否一致，最好定义一个新的方法。