第三章 从Object继承一些基本方法时的注意事项
原翻译 对于所有对象都通用的方法
Object 对象是Java中一切对象的始祖，可以说所有的类都继承了这个类。关于这个类的介绍请看 Java API，这一章主要讲了覆盖Object 类可以覆盖的方法有finalize()，equals()，hashCode()，toString()，clone()，其中finalize()在上一章已经讲过了，这章主要讲了其他几个方法覆盖时的一些注意事项 和实现Comparable接口的注意点
第八条 覆盖equals()方法时需要遵守的约定
Object 中的equals方法如下：
public boolean equals(Object obj) {
return (this == obj);
}
根据Object的规范，这个方法有5个可以踩的坑：
1.自反性
对于非null的x，x.equals(x)必须返回ture。好吧，其实这条不是很容易踩到，我们跳过他。
2.对称性
看一个实现大小写不敏感的类，代码如下 ：
class CaseInsensitiveString {
private final String s;
public CaseInsensitiveString(String s) {
super();
this.s = s;
}
public boolean equalsIgnoreCase(String s) {
return s.toLowerCase().equals(this.s.toLowerCase());
}
@Override
public boolean equals(Object o) {
if (o instanceof CaseInsensitiveString) {
return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
}
if (o instanceof String) {
return s.equalsIgnoreCase((String) o);
}
return false;
}
}
这个类覆写了equals()方法，不仅这个类的实例之间的比较不区分大小写，而且这个类与String类的比较也不区分大小写，乍看之下似乎挺好的，但是类的作者忘了String的equals是区分大小写的。这就造成了下面的代码：
String s = "abc";
CaseInsensitiveString caseInsensitiveString = new CaseInsensitiveString("ABC");
System.out.println(s.equals(caseInsensitiveString));
System.out.println(caseInsensitiveString.equals(s));
产生了下面的结果
这明显是不合理的。
3.传递性
如果第一个对象equals第二个对象返回ture，第二个对象equals第三个对象也返回ture，那么第一个对象equals第三个对象也要返回ture。
假设你有这么一个表示苹果的类
class Apple{
public int weight;
public int height;
public Apple(int weight, int height) {
this.weight = weight;
this.height = height;
}
@Override
public boolean equals(Object o) {
if(!( o instanceof Apple)) return false;
Apple apple = (Apple)o;
return apple.weight == this.weight && apple.height == this.height;
}
}
然后你想拓展一下这个类,添加一点颜色信息。
class ColorApple extends Apple{
public String color;
public ColorApple(int weight, int height,String color) {
super(weight, height);
this.color = color;
}
@Override
public boolean equals(Object o) {
return super.equals(o);
}
}
像这样。这样虽然有颜色的苹果比较时不违反equals的规范，但是比较时忽略了color信息，这显然是不合理的。但是如果你把代码改成下面这样
@Override
public boolean equals(Object o) {
if(!( o instanceof ColorApple)) return false;
return super.equals(o) && this.color == ((ColorApple)o).color;
}
这样虽然在比较的时候加上了颜色的信息。 但是这样有个坑，比如Apple(1,2)跟ColorApple(1,2,3)的比较违反了对称性。如果想保证对称性，可以将代码修改成下面的样子
@Override
public boolean equals(Object o) {
if(!( o instanceof Apple)) return false;
if(!(o instanceof ColorApple)) return o.equals(this);
return super.equals(o) && this.color == ((ColorApple)o).color;
}
但是这样会使equals的比较失去传递性。肿么办呢~ 书上说这是面向对象中关于等价关系的一个基本问题
我们无法在拓展可实例化的类的同时，即增加新的属性，又同时保留equals的约定
比如java.sql.Timestamp对java.util.Date进行了拓展，并增加了nanoseconds域，Timestamp的equals实现就违反了对称性。所以Timestamp对象跟Date对象不能出现在同一个集合中，不然会发生奇怪的事情。
书上说用getClass方法代替instanceof方法可以同时满足上面这两条，但是这只在单例的时候适用。其他大概就是没办法了吧。。。。。
一致性
如果两个对象相等，那么他们应该是一直保持相等的。
不要使equals对象依赖于不可靠资源。
非空性
大概就是equals方法里面要加上if(!( o instanceof MyType)) return false; 这么一句。
equals方法坑辣么多，能不覆盖就经历不要覆盖。但是实在要覆盖肿么办呢？书上给了几条高质量实现equals方法的建议
- 可以考虑用==操作来检查是否为这个对象的引用
- 使用instanceof检查参数是否为正确的类型
- 把参数转成正确的类型
- 检查类中的每个关键域
- 三省：对称否？传递否？一致否？
书上还有一些告诫
1.覆盖equals的时候一定要覆盖hashCode(见第九条)
2.不要指望equals方法过于智能，差不多就行了...
3.不要讲equals中的Object参数换成其他参数。
public boolean equals(MyType o){
...
}
这逗比写法会导致一些很奇怪的错误。用@Override 可以避免犯这个错误。
第九条 覆盖hashCode是的一些注意事项
原翻译： 覆盖equals是总要覆盖hashCode
在覆盖equals方法的类中，也必须覆盖hashCode方法，如果不这样的话，会违反Object.hashCode的通用约定。这样会导致该类没有办法跟HashMap、HashSet之类的集合类一起愉快的工作。
hashCode的规范请见Object规范
第十条 覆盖toString()方法
写过java的都知道Object的toString()方法放回的是类名称@类的hashCode，这样似乎不优雅。 所以我们能覆盖toString()还是覆盖吧。让他输出一些我们需要的信息的说（又一提升逼格的方式）。
第十一条 谨慎的覆盖clone()方法
- 如果对象包含的域引用了可变的对象时，clone()方法要记得连可变对象一起复制了。
- clone() 与 引用可变对象的final域的正常用法是不兼容的，除非原始对象和克隆对象之间可以安全的共享对象。
- clone() hashTable之类的东西的时候可能会有些坑，要每个元素一个一个深度拷贝过去的说
- 如果是线程安全的类要实现Cloneable接口，那么要自己弄好同步的事情
最后书上说：** 这个方法能不覆盖就不要覆盖了吧..... **
第十二条 考虑实现Comparable接口
这个接口实现了能方便对象之间的比较，这样能方便该类跟许多泛型算法和集合框架进行愉快的合作，项目不紧的话能实现就实现了吧。
