Effective-java-读书笔记之对于所有对象都通用的方法

第10条 覆盖equals时请遵守通用约定

如果不覆盖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, 不要弄错.

第11条 覆盖equals时总要覆盖hashCode

在每个覆盖了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缓存在对象内部.

第12条 始终要覆盖toString

Object类的toString实现: 类名@散列码的无符号十六进制表示法.

当对象被传递给println, printf, 字符串联操作符(+)以及assert或者被调试器打印出来时, toString方法会被自动调用.

提供好的toString方法可以使类使用起来更加舒适, 更利于调试.

实践上, toString方法应该返回对象中所有感兴趣的信息.

在实现toString的时候, 必须要做出一个很重要的决定: 是否在文档中指定返回值的格式.

* 好处: 标准, 明确, 适合人阅读, 容易在对象和它的字符串表示法之间来回转换.

* 不足: 一旦指定, 就必须坚持这种格式, 如果要改变就会破坏原来的代码和数据.

无论是否指定了格式, 都应该在文档中说明意图.

无论是否指定格式, 都应该为toString返回值中包含的所有信息, 提供一种访问途径.

如果不这么做, 如果想获取某个信息, 就得解析字符串, 降低性能, 解析过程也易出错, 会导致系统不稳定, 如果格式发生变化, 还会导致系统崩溃.

第13条 谨慎地覆盖clone

Cloneable接口没有包含任何方法.

它决定了Object中受保护的clone方法实现的行为:

如果一个类实现了Cloneable, Object的clone方法返回该对象的逐域拷贝, 否则就会抛出CloneNotSupportedException. (接口的一种极端非典型的用法.)

来自Object规范中的clone方法的通用约定:

创建和返回对象的一个拷贝. 这个拷贝的精确含义取决于该对象的类.

通常要求:

* x.clone() != x

* x.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方法, 阻止子类实现.

另一个实现对象拷贝的方法(更好的方法)是提供一个拷贝构造器或者拷贝工厂.

第14条 考虑实现Comparable接口

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.