软件构造3.4ADT设计之对象判相等（ADT和OOP中的等价性）

问题引入：Java中有两种判相等的方法：== 和equals(), 其中 == 判断的是引用等价性，而equals()会通过比较对象内部的属性或内容，判断的是对象等价性。故对基本数据类型，使用 == 判定相等，对对象类型，使用equals()。因为在Object中实现的equals()是直接判断引用等价性，所以在自定义ADT时，需要重写Object的equals()方法。

问题：如何为自定义的ADT正确实现equals()?

判断相等的角度（需要站在用户的角度来看）：

1. 利用AF来定义等价性，即从用户的角度来判断是否等价。
2. 根据用户的外部观察来判断两个实例是否相等。即站在外部观察者角度：对两个对象调用任何相同的操作（所有的observer），都会得到相同的结果，则认为这两个对象是等价的。

写equals()的要求

1. 首先，在每次重写时一定要加上@Override标识，否则为重载。
2. 前面说过尽量不使用instanceof,因为它是运行时的动态类型检查，不是静态类型检查，但是在equals()方法中除外，我们需要检查传进来的参数类型是否匹配当前要检测的类型。
3. 在你重写equals()方法时，要注意符合等价关系，即满足自反，对称和传递性。符合一致性，即多次调用结果相同。符合相等的对象，其hashCode()的结果必须一致的要求。故也需要同时重写hashCode()。符合“Non-null” – a.equals(null) returns false。
4. 两种类型的equals()判断：

• immutable类型：
  直接比较AF的值是否相等即可，必须重写equals()和hashCode()方法。因为对于immutabe类型的对象来说，观察等价性和行为等价性是同一的，因为没有任何mutator。
• mutable类型 ：
  对可变类型来说，往往倾向于只实现严格的观察等价性，但这样可能导致bug。例如：
  
  如果某个mutable 的对象包含在Set 集合类中，当其发生改变后，集合类的行为不确定 。
  故对于可变类型，尽量实现行为等价性，即引用相等，故无需重写equals()和hashCode()方法。如果一定要判断两个可变
  对象看起来是否一致，最好定义一个新的方法，如similar()。

自动打包和等价性

基本数据类型和它们的对象数据类型的相等，例如，int和Integer.

Integer的构造函数中对-128到127之间的数字已经创建好了对象，不用重新创建，所以其引用也相同，即对上面的例子有
x == y -> true