图文无关

第三章 从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方法的建议

1. 可以考虑用==操作来检查是否为这个对象的引用
2. 使用instanceof检查参数是否为正确的类型
3. 把参数转成正确的类型
4. 检查类中的每个关键域
5. 三省：对称否？传递否？一致否？

书上还有一些告诫
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()方法

1. 如果对象包含的域引用了可变的对象时，clone()方法要记得连可变对象一起复制了。
2. clone() 与 引用可变对象的final域的正常用法是不兼容的，除非原始对象和克隆对象之间可以安全的共享对象。
3. clone() hashTable之类的东西的时候可能会有些坑，要每个元素一个一个深度拷贝过去的说
4. 如果是线程安全的类要实现Cloneable接口，那么要自己弄好同步的事情

最后书上说：** 这个方法能不覆盖就不要覆盖了吧..... **

第十二条 考虑实现Comparable接口

这个接口实现了能方便对象之间的比较，这样能方便该类跟许多泛型算法和集合框架进行愉快的合作，项目不紧的话能实现就实现了吧。