Effective Java-第三章 对于所有对象都通用的方法

一、覆盖equals时请遵守通用约定

覆盖equals方法看起来似乎很简单，但是有很多覆盖方式会导致错误，并且后果非常严重。最容易避免这类问题的办法就是不覆盖equals方法，如果满足一下任意一个问题，就可以不用覆盖equals方法：

• 类的每个实例本质上都是唯一的
• 不关心类是否提供了“逻辑相等(logical equality)”的测试功能
• 超类已经覆盖了equals，从超类继承过来的行为对于子类也是合适的
• 类是私有的或是包级私有的，可以确定它的equals方法永远不会被调用

什么时候应该覆盖equals方法呢？
当一个类具有自己特有的“逻辑相等”概念，而且超类还没有覆盖equals以实现期望的行为。这通常属于“值类（value class）”的情形。
有一种“值类”不需要覆盖equals方法。枚举类型就属于这种类。

在覆盖equals方法的时候，你必须要遵守它的通用约定。下面是约定的内容，来自Object的规范[JavaSE6]：
equals方法实现了等价关系（equivalence relation）：

• 自反性（reflexive）。 对于任何非null的引用值x，x.equals(x)必须返回true。
• 对称性（symmetric）。 对于任何非null的引用值x和y，并且仅当y.equals(x)==true时，x.equals(y)必须返回true。
• 传递性（transitive）。 对于任何非null的引用值x、y和z，如果x.equals(y)==true,并且y.equals(z)==true，那么x.equals(z)==true.
• 一致性（consistent）。 对于任何非null的引用值x和y，只要equals的比较操作在对象中所用的信息没有被修改，多次调用x.equals(y)就会一致地返回true，或者一致地返回flase。
• 非空性（non-nullity）。对于任何非null的引用值x，x.equals(null)必须返回false。

结合这些要求，得出了一下实现高质量equals方法的诀窍：

1. 使用==操作符检查“参数是否为这个对象的引用”。如果是，则返回true。这只不过是一种性能优化，如果比较操作有可能很昂贵，就值得这么做。
2. 使用instanceof操作符检查“参数是否为正确的类型”。如果不是，则返回false。所谓“正确的类型”是指equals方法所在的那个类。有些情况下，是指该类所实现的某个接口。如果类实现的接口改进了equals约定，允许在实现了该接口的类之间进行比较，那么就是用接口。集合接口如Set、List、Map和Map.Entry具有这样的特性。
3. 把参数转换成正确的类型。因为转换之前进行过instanceof测试，所以确保会成功。
4. 对于该类中的每个“关键（significant）”域，检查参数中的域是否与该对象中对应的域相匹配。如果这些测试全部成功，则返回true；否则返回false。如果第2步中的类型是个接口，就必须通过接口方法访问参数中的域；如果该类型是个类，也许就能够直接访问参数中的域，这要取决于它们的可访问性。
5. 当你编写完成了equals方法之后，应该问自己三个问题：他是否对称的、传递的、一致地？并且不要只是自问，还要编写单元测试来检验这些特性！如果答案是否定的，就要找出原因，再相应地修改equals方法的代码。当然，equals方法也必须满足其他两个特性（自反性和非空性），但是这两种特性通常会自动满足。

根据上面诀窍构建的equals方法的具体例子，后面会有标记！！！下面是最后的一些告诫：

• 覆盖equals是总要覆盖hashCode。
• 不要企图让equals方法过于智能。如果只是简单的测试域中的值是否相等，则不难做到遵守equals约定。如果想过度地去寻求各种等价关系，则很容易陷入麻烦之中。把任何一种别名形式考虑到等价的范围内，旺旺不会是个好主意。例如，File类不应该试图把指向同一个文件的符号链接（symbolic
  link）当做相等的对象来看待。所幸File类没有这样做。

• 不要讲equals生命中的Object对象替换为其他的类型。程序员编写出下面这样的equals方法并不鲜见，这会使程序员划伤数个小时都搞不清为什么它不能正常工作：

  public boolean equals(MyClass o) { // 代码段 }
  问题在于，这个方法并没有覆盖Object.equals,因为它的参数应该是Object类型，相反，它重载（overload）了Object.equals。（这种错误可以用@Override注解来规避）

二、覆盖equals是总要覆盖hashCode

一个很常见的错误根源在于没有覆盖hashCode方法。在每个覆盖了equals方法的类中，也必须覆盖hashCode方法。如果不这样做的话，就会违反Object.hashCode的通用约定，从而导致该类无法结合所有基于hash的集合一起正常运作，这样的集合包括HashMap、HashSet和Hashtable。

下面是约定的内容，摘自Object规范[JavaSE6]:

• 在 Java 应用程序执行期间，在对同一对象多次调用 hashCode 方法时，必须一致地返回相同的整数，前提是将对象进行 equals比较时所用的信息没有被修改。从某一应用程序的一次执行到同一应用程序的另一次执行，该整数无需保持一致。
• 如果根据 equals(Object) 方法，两个对象是相等的，那么对这两个对象中的每个对象调用 hashCode方法都必须生成相同的整数结果。
• 如果根据 equals(java.lang.Object) 方法，两个对象不相等，那么对这两个对象中的任一对象上调用 hashCode方法不要求一定生成不同的整数结果。但是，程序员应该意识到，为不相等的对象生成不同整数结果可以提高哈希表的性能。

import java.util.HashMap;
import java.util.Map;

public final class PhoneNumber {
    private final short areaCode;
    private final short prefix;
    private final short lineNumber;

    public PhoneNumber(int areaCode, int prefix, int lineNumber) {
        rangeCheck(areaCode, 999, "area code");
        rangeCheck(prefix, 999, "prefix");
        rangeCheck(lineNumber, 9999, "line number");
        this.areaCode = (short) areaCode;
        this.prefix = (short) prefix;
        this.lineNumber = (short) lineNumber;
    }

    private static void rangeCheck(int arg, int max, String name) {
        if (arg < 0 || arg > max) {
            throw new IllegalArgumentException(name + ": " + arg);
        }
    }

    @Override
    public boolean equals(Object o) {
        if(o == this) {
            return true;
        }
        if (!(o instanceof PhoneNumber)) {
            return false;
        }
        PhoneNumber pn = (PhoneNumber) o;
        return pn.lineNumber == lineNumber && pn.prefix == prefix && pn.areaCode == areaCode;
    }

    public static void main(String[] args) {
        Map<PhoneNumber, String> m = new HashMap<PhoneNumber, String>();
        m.put(new PhoneNumber(707, 867, 5309), "Jenny");

        System.out.println(m.get(new PhoneNumber(707, 867, 5309)));
    }
}

这段代码的equals方法是根据上面所说的诀窍构造出来的。
这是你可能希望运行后放回“Jenny”，但是实际上返回的是null。为什么呢？注意，这里涉及两个PhoneNumber实例：第一个被用于插入到HashMap中，第二个实例与第一个相等，被用于获取。由于PhoneNumber类没有覆盖hashCode方法，从而导致两个相等的实例具有不相等的hash码，违反了hashCode的约定。因此，put方法把电话号码对象存放在一个hash bucket中，get方法却在另一个hash bucket中查找这个电话号码。即食这两个实例正好被放在同一个hash bucket中，get方法也必定会返回null，因为HashMap有一项优化，可以将与每个向相关联的Hash码缓存起来，如果散列码不匹配也不必检验对象的等同性。

修正这个问题很简单，只需为PhoneNumber类提供一个适当的hashCode方法即可。编写一个合法但并不好用的hashCode方法没有任何价值。例如

@Override
    public int hashCode() {
        return 16;
    }

上面这个hashCode方法是合法的，因为他确保了相等的对象总是具有同样的hash码。但它也是恶劣的，因为他使得每个对象都具有同样hash码。
一个好的hash函数通常倾向于“为不相等的对象产生不相等的hash码”，下面给出一种简单的hash函数：

1. 把某个非零的常数值，比如说17，保存在一个名为result的int类型的变量中。

2. 对于对象那个中每个变量（指equals方法中对比的变量），完成以下步骤：
   为该变量计算int类型的hash码c:

   • 如果该变量是boolean类型，则计算(f ? 1 : 0)。
   • 如果该变量是byte、char、short或者int类型，则计算(int)f。
   • 如果该变量是long类型，则计算(int)(f^(f>>>32))
   • 如果该变量是float类型，则计算Float.floatToIntBits(f)。
   • 如果该变量是double类型，则计算Double.doubleToLongBits(f)，再按照long型计算。
   • 如果该变量是一个对象引用，并且该类的equals方法通过递归地调用equals方式来比较这个变量，则同样为这个变量递归地调用hashCode。如果需要跟复杂的比较，则为这个变量计算一个“范式（canonical
     representation）”，然后针对这个范式调用hashCode。如果这个与的值为null,则返回0（或者其他的常数，但通常为0）。
   • 如果该变量是一个数组，则要吧每一个元素当做单独的变量来处理，然后再根据上面的情况处理。

   按照下面公式，把步骤2中计算得到的hash码合并到result中
   result= 31 * result + c;

3. 返回result。
4. 测试hashCode。

记住排除equals中没有计算的变量。
这样写出的HashCode方法如下

@Override
    public int hashCode() {
        final int prime = 17;
        int result = 1;
        result = prime * result + areaCode;
        result = prime * result + lineNumber;
        result = prime * result + prefix;
        return result;
    }

当然，Eclipse也可以自己生成这个方法，只不过是prime不同罢了。

如果一个类是不可变的，并且计算hash码的开销也比较大，就应该考虑把hash码缓存在对象内部，而不是每次请求的时候都重新计算hash码。如果你觉得这种类型的大多数对象会被用做hash keys，就应该在创建实例的时候计算hash码。否则，可以选择“延迟初始化（lazily initialize）”hash码，一直到hashCode被第一次调用的时候才初始化。代码如下：

private volatile int hashCode;

@Override
    public int hashCode() {
        int result = hashCode;
        if (result == 0) {
            final int prime = 17;
            result = 1;
            result = prime * result + areaCode;
            result = prime * result + lineNumber;
            result = prime * result + prefix;
            return result;
        }
    }

当然这个hash函数只是一个简单的hash函数，编写hash函数是个研究课题，最好留给数学家和理论方面的计算机科学家来完成，但是本hash函数对于绝大多数应用程序而言已经足够了。

还有一点需要注意，不要试图从hash码计算中排除掉一个对象的关键部分来提高性能。虽然这样得到的hash函数运行起来可能更快，但是它的效果不见得会好，可能会导致hash表慢到根本无法使用。

三、始终覆盖toString

虽然java.lang.Object提供了toString方法的实现，但它返回的字符串通常不是大家想要看到的，而是它包含类的名称，以及一个“@”符号，接着是hash码的无符号十六进制表示法。
toString的通用约定支出，被返回的字符串应该是一个“简洁的，但信息丰富，并且易于阅读的表达方式”
在实际应用中，toString方法应该返回对象中包含的所有值得关注的信息

-未完待续-

五、考虑实现Comparator接口

考虑实现Comparator接口