本章讲何时以及如何覆盖Object的非final的方法.
Comparable.compareTo方法具有类似特征, 所以也放在本章讨论.
如果不覆盖equals方法, 类的每个实例都只与它自身相等.
如果满足以下任何一个条件, 就不需要覆盖equals方法:
- 类的每个实例本质上都是唯一的. (代表活动实体的类如Thread.)
- 不关心类是否提供了逻辑相等的测试功能.
- 超类已经覆盖了
equals, 从超类继承过来的行为对于子类也是合适的. (Set, List, Map). - 类是私有或者包可见的, 可以确定它的
equals方法永远不会被调用. 这种情况下, 可以覆盖equals方法, 抛出AssertionError. 以防意外调用.
什么时候应该覆盖equals()方法呢?
如果类具有逻辑相等的概念, 通常属于值类(value class)的情形.
例外: 实例受控的值类: 枚举, 一个值对应一个实例, 所以不需要覆盖equals.
覆盖equals方法的时候, 必须要遵守通用约定:
- 自反性(reflexive): 对象必须等于其自身.
- 对称性(symmetric): 任何两个对象关于它们是否相等的结果保持一致.
- 传递性(transitive): 如果一个对象等于第二个对象, 第二个对象等于第三个对象, 则第一个对象一定等于第三个对象.
- 一致性(consistent): 如果两个对象相等, 它们就必须始终保持相等, 除非它们被修改了.
- 非空性(non-nullity): 所有的对象都必须不等于null.
实现高质量equals方法的诀窍:
- 使用
==操作符检查参数是否为这个对象的引用, 如果是, 则返回true. - 使用
instanceof操作符检查参数是否为正确的类型, 如果不是, 则返回false. - 把参数转换成正确的类型.
- 对于该类中的每个关键域, 检查参数中的域是否与该对象中对应的域相匹配.
- 当你编写完成了
equals方法之后, 应该问自己三个问题: 它是否是对称的, 传递的, 一致的? (其他两个特性通常会自动满足.)
注意覆写方法加上@Override, equals方法的参数类型是Object, 不要弄错.
在每个覆盖了equals方法的类中, 也必须覆盖hashCode方法.
如果不这样做的话, 就会违反Object.hashCode的通用约定, 从而导致该类无法结合所有基于散列的集合一起正常运作, 这样的集合包括HashMap, HashSet和Hashtable.
通用约定:
- 程序执行期间, 只要对象的
equals方法的比较操作所用到的信息没有被修改, 那么多次调用hashCode方法都必须始终如一地返回同一个整数. (在应用程序多次执行的过程中, 每次执行所返回的整数可以不一致.) - 如果两个对象根据
equals比较相等, 那么hashCode结果应该相同. - 如果两个对象根据
equals比较不相等, 则hashCode不一定要产生不同的整数结果. (但是不相等的对象产生不同的hashCode有可能提高散列表的性能. 一个好的散列函数通常倾向于为不相等的对象产生不相等的散列码.)
Hashcode的计算:
- 初始值result = 17 (非零常数值, 这样散列值为0的域就会影响到结果).
- 对于对象中
equals涉及的每个域, 计算出散列值c. result = 31 * result + c. (乘法使得散列值依赖于域的顺序, 31奇素数, 可以用移位和减法来代替乘法.)
可以把冗余域排除在外, 即一个域的值可以根据其他域的值计算出来. 如果一个类是不可变的, 并且计算hashCode的开销也比较大, 就应该考虑把hashCode缓存在对象内部.
Object类的toString实现: 类名@散列码的无符号十六进制表示法.
当对象被传递给println, printf, 字符串联操作符(+)以及assert或者被调试器打印出来时, toString方法会被自动调用.
提供好的toString方法可以使类使用起来更加舒适, 更利于调试.
实践上, toString方法应该返回对象中所有感兴趣的信息.
在实现toString的时候, 必须要做出一个很重要的决定: 是否在文档中指定返回值的格式.
- 好处: 标准, 明确, 适合人阅读, 容易在对象和它的字符串表示法之间来回转换.
- 不足: 一旦指定, 就必须坚持这种格式, 如果要改变就会破坏原来的代码和数据. 无论是否指定了格式, 都应该在文档中说明意图.
无论是否指定格式, 都应该为toString返回值中包含的所有信息, 提供一种访问途径.
如果不这么做, 如果想获取某个信息, 就得解析字符串, 降低性能, 解析过程也易出错, 会导致系统不稳定, 如果格式发生变化, 还会导致系统崩溃.
Cloneable接口没有包含任何方法.
它决定了Object中受保护的clone方法实现的行为:
如果一个类实现了Cloneable, Object的clone方法返回该对象的逐域拷贝, 否则就会抛出CloneNotSupportedException. (接口的一种极端非典型的用法.)
来自Object规范中的clone方法的通用约定:
创建和返回对象的一个拷贝. 这个拷贝的精确含义取决于该对象的类.
通常要求:
x.clone() != xx.clone().getClass() == x.getClass()x.clone().equals(x)通常要求这三个表达式都为true, 但不是绝对.
如果你覆盖了非final类中的clone方法, 则应该首先调用super.clone得到对象.
对于实现了Cloneable的类, 我们总是期望它也提供一个功能适当的公有的clone方法, 通常, 需要该类的所有超类都提供了行为良好的clone方法.
clone方法的返回值应该是当前类(而不是Object). 协变返回类型(covariant return type): 覆盖方法的返回类型可以是被覆盖方法的返回类型的子类.
immutable的类不应该提供clone方法.
引用对象的clone: clone方法不应该伤害到原始对象, 所以对引用对象应该递归地调用clone.
Cloneable和一般的指向mutable对象的final域使用不兼容(除非这些域可以在对象和它的克隆之间安全共享).
所以为了让一个类可克隆, 有时候需要移除一些域之前的final修饰符.
散列表数据的深度拷贝. (三种方法: 递归, 迭代, 后续put赋值.)
clone方法中不能调用非final非private的方法, 子类可能会覆盖, 修改行为.
Object的clone方法声明了throw CloneNotSupportedException, 覆写以后就不用声明了.
如果一个类只是为了继承而设计的, 那么它不应该实现Cloneable. 要么学Object类, 让子类自由决定是否实现; 要么实现一个抛出异常的clone方法, 阻止子类实现.
另一个实现对象拷贝的方法(更好的方法)是提供一个拷贝构造器或者拷贝工厂.
compareTo方法是Comparable接口中唯一的方法, 允许进行等同性和顺序比较:
将对象与指定的对象进行比较, 当该对象小于, 等于或大于指定对象的时候, 分别返回一个负整数, 零或正整数.
由compareTo施加的等同性测试, 也一定遵守相同于equals约定所施加的限制条件: 自反性, 对称性和传递性.
强烈建议(x.compareTo(y) == 0) == (x.equals(y)).
比较对象引用域可以是通过递归地调用compareTo方法来实现. 如果一个域并没有实现Comparable接口, 或者你需要一个非标准的排序关系, 可以使用一个显式的Comparator来代替.
本书之前的版本是这样建议的:
比较整数型基本类型的域, 可以用关系操作符`<`和`>`.
浮点域用`Double.compare`或`Float.compare`. (浮点值没有遵守compareTo的通用约定.)
从Java 7开始, 所有的基本类型的装箱类型都提供了静态的compare方法, 所以不再建议使用<和>.
如果一个类有多个关键域, 必须从最关键的域开始, 逐步进行到所有的重要域, 如果某个关键域产生了非零的结果, 则整个比较结束, 并返回该结果, 否则则进一步比较下一个域.
Java 8提供了一些comparator构造的方法, 比如comparingInt, thenComparingInt, comparing等, 可以链式组合使用.
由于compareTo方法并没有指定返回值的大小, 而只是指定了符号, 所以可以利用这一点进行简化.
反例: 不要用两个数相减的方法: 注意可能会溢出导致错误, 并且这样做并没有明显的性能改善.
-> 推荐用静态的Integer.compare方法或者comparingInt来构造Comparator.