深入理解Collections API

　　为了使这个例子短一些，该类受到了一点限制：它不支持中间名，它要求必须同时具有first name 和 last name, 而这不是在全世界都通用的。尽管如此，这个例子仍有几个重要之处:

　　Name 对象是不变的（ immutable）。作为相等、不变类型的所有其它事情就是如何做的问题，特别是对那些将被用来作为 Sets 中的元素或 Maps 中的键的对象来说，更是如此。如果你对这些 对象集 中的元素或键做了更改，这些 对象集 将中断。

　　构造函数可检查它的参数是否为 null。 这可以保证所有的Name 对象都能很好地形成。因而没有其它方法会扔出NullPointerException.

　　hashCode 方法被重新定义。对重新定义 equals 方法的任意类来说，这是必需的（essential）。 一般约定（general contract）需要 Object.equals. (Equal 对象必须具有相等的哈希代码) 。

　　如果特定对象为 null，或一个不适当的类型， equals 方法则返回 false。 在这种情况下， compareTo 方法扔出一个运行时异常。这两个行为都是各自方法的一般约定所必需的。

　　toString 方法已被重新定义，从而可以以人们能够读懂的形式打印 Name 。这总是一个好主意，特别是对要被放入对象集 中的对象来说，更有益处。各种 对象集 类型的 toString 方法依赖它们的元素、键和值的 toString 方法。

　　由于这一节介绍的是有关元素排序的问题，因而让我们稍微多谈一点 Name 的 compareTo 方法。它实现标准的姓名-排序算法，在该算法中，last name 优先于 first name。这恰恰是你在一个natural ordering（自然排序）中所想要的。 如果自然排序不自然，那才容易引起混乱呢!

　　请看 compareTo 是如何被实现的，因为它是相当典型的。首先，你将 Object 参数转换为适当类型； 如果参数类型是不适当的，则会扔出一个适当的异常(ClassCastException)；那么你应该比较对象的最重要部分（在此案例中为 last name)。通常，你可以使用该部分的类型的自然排序。 在次案例中，该部分是一个 String, 并且自然的（按词典顺序的）排序正是所要求的。如果比较的结果是空（它表示等同性）之外的其它东西，你就做完了：你可以返回结果。 如果最重要的部分是相等的，你就应该继续比较次重要部分。在此案例中，只有两个部分 (first name and last name)。 如果有更多的部分，你就应该以显而易见的方式继续进行，直到发现两个不相等的部分（否则你就应该比较最不重要的部分），这时，你就可以返回比较结果了。 这是 一个建立 Name 对象列表并对它们进行排序的小程序: