Effective-Java读书笔记08 Obey the general contract when overriding equals 重写equals方式时需要遵守通用规则

Object中的equals只有当比较的是"自己"时才返回true.

public boolean equals(Object obj) {
    return (this == obj);
}

当我们重写改方法时, 非常容易出错, 所以作者给我们的第一个建议是…别重写(…) . 当我们不需要做逻辑判断的时候尽量不要去重写该方法.

对于需要做逻辑判断的类, 称为value class, 比如Integer和Date, 这些类就是表示某些值, 所以equals方法需要被重写. 但是对于单例的类来说就不需要了, 因为只有该类只有一个对象, 所以使用Object的equals就可以了, 比如Enum.

当重写equals方法时需要遵守以下规则

1. 自反性: 对于任何非空对象x, x.equals(x)必须返回true.
2. 对称性: 对于任何非空对象x和y, 如果x.equals(y)返回true, 那么y.equals(x)必须返回true.
3. 传递性: 对于任何非空对象x, y, z. 如果x.equals(y) 返回true, y.equals(z)返回true, 那么x.equals(z)必须返回true.
4. 一致性: 对于任何非空对象x和y, 当对象比较信息没有发生变化时, 多次调用equals方法返回的结果是一致的.
5. 非空性: 对于任何非空对象x, x.equals(null)必须返回false.

这几条规则初看有点绕, 仔细一想又感觉是废话~ 我们一条一条看下.

自反性

我实在想不出除了估计一直返回false, 还有什么其他方式可以违法自反性. 这条规则想违反都难.

对称性和传递性

相比于自反性, 对称性和传递性非常容易违反, 有多容易? jdk提供的java.sql.Timestamp类就违反了这两条规则, 该类继承与java.util.Date, 执行如下代码可以说明.

public static void main(String[] args) {

    Date date = new Date();
    Timestamp timestamp = new Timestamp(date.getTime());
    System.out.println("date.equals(timestamp) : " + date.equals(timestamp);
    System.out.println("timestamp.equals(date) : " + timestamp.equals(date);
}

// 结果
自反性
date.equals(timestamp) : true
timestamp.equals(date) : false
传递性
date.equals(timestamp2) : true
timestamp1.equals(timestamp2) : true
timestamp1.equals(date) : false

分别看下二者equals的实现方式

// Date
public boolean equals(Object obj) {
    return obj instanceof Date && getTime() == ((Date) obj).getTime();
}

// Timestamp, 对, 它实现了两个equals方法
public boolean equals(Timestamp ts) {
    if (super.equals(ts)) {
        if  (nanos == ts.nanos) {
            return true;
        } else {
            return false;
        }
    } else {
        return false;
    }
}

public boolean equals(java.lang.Object ts) {
    if (ts instanceof Timestamp) {
    return this.equals((Timestamp)ts);
    } else {
    return false;
    }
}

有源码可知, Date首先判断是否为Date类(Timestamp是Date子类), 然后判断二者毫秒值是否相等. 但是Timestamp对于非Timestamp对象直接返回false. 如果混用二者的话, 很容易出现莫名其妙的问题. 深入了解下, Timestamp是在Date基础上扩展了纳秒值, 相当于在原属性上多了一个属性. 对于这种情况作者给出了一个相当不错的实现方式: 不使用继承而是组合的方式, 将"父类"作为一个属性, 这样的话在重写equals时就不会出现上述问题了. 实现代码如下(自己简化代码, 实际不存在):

public class Timestamp{
    private Date date;
    private long nanos;

    @Override
    public boolean equals(Object obj) {
        if (ts instanceof Timestamp) {
            Timestamp ts = (Timestamp)obj;
            return date.equals(ts.getDate) && nanos == ts.nanos)
        } else {
            return false;
        }
    }
}

一致性

初看这条规则是同样想象不到什么情况会违反这条规则, 作者给出了一个例子, java.net.URL类, 该类的equals方法会比较IP等需要网络的资源, 所以这个比较结果可能会跟着时间变化. 针对这种情况作者建议尽量使用可靠的数值进行比较, 但是对于URL的情况, 作者也没有很好的解决办法.

非空性

通常实现equals时都会使用instanceOf判断, 所以不需要特殊的进行非空判断.

写好equals方法

public class Foo{

    @Override // 必须写@Override注解, 可以防止开发人员重载多个equals方法, 
             //造成莫名其妙错误
    public boolean equals(Object obj) {
        if(obj instanceOf Foo) { // 使用instanceOf, 排除null和其他对象
            // 使用可靠性数值进行比较.
            // 尽量简单
        } else {
            return false;
        }
    }
}