Effective Java(3rd)-Item26 不要使用原始类型

  首先，有一些条款。声明具有一个或多个类型参数的类或接口是泛型类或接口 [JLS, 8.1.2, 9.1.2].。例如，接口List就有单独的类型参数，E，代表了它的元素类型。该接口的完整名字叫做List(读作“list of E”),但是人们通常简读为List。泛型类和接口统称为泛型类型。
  每个泛型类型定义一组参数化类型，包括类或接口名称，后面是与泛型类型的形式类型参数相对应的实际类型参数的角度括号内的列表[JLS, 4.4,4.5].例如，List（读作“list of string”）是一个参数化类型，它表示了一个列表包含的所有元素的类型都是String（String就是形参E相对应的实际类型参数）。
  最后，每个泛型类型都定义了一个原生类型，它是在没有任何伴随类型参数的情况下使用的泛型类型的名称 [JLS, 4.8]。例如，List对应的原生类型就是List。原生类型的行为就好像所有泛型类型信息都被类型声明给擦除了。它们的存在主要是为了与预泛型代码兼容。
  在Java中加入泛型之前，这将是一个示例性的集合声明。在Java9中，它仍然是合法的，但是远非典范：

image.png

  如果你在今天使用这个声明，然后意外地在你的集合中加入coin，错误的插入将编译并允许而不会出错（尽管编译器确实发出了模糊的警告）：

image.png

  你不会得到错误直到你尝试在stamp集合中检索coin：

image.png

  正如本书所提到的，在错误发生后尽快发现错误是有益的，最好是在编译时。在这种情况下，你将不会发现错误直到运行时，在错误发生很久之后，并且可能与包含错误的代码相距较远的代码中发现错误。一旦你看到ClassCastException，你不得不搜索代码库寻找将coin放入stamp集合的方法引用。编译器不能帮助你，因为它不能理解注释的描述：“只能包含Stamp实例”。
  使用泛型，类型声明包含信息，而不是注释：

image.png

  通过这个声明，编译器知道了stamp应该有且仅包含Stamp实例并保证这是正确的，假设整个代码库编译而不会发生任何警告（或抑制；见 item27 ）。当stamps被参数化类型声明而声明，错误地插入将会产生编译时错误消息，并确切地告诉你哪里错了：

image.png

  编译器从集合中检索元素并保证为你插入不可见的强制类型转换时不会失败。（假设你的所有代码没有审核过程或抑制任何编译警告）。虽然意外地将coin插入stamp集合的想法可能是有点牵强，但是这个问题是存在的。·比如，很容易想象将BigInteger放入只包含BigDecimal实例的集合。
  如前所述，使用原生类型是合法的（没有类型参数的泛型类型），但是你不该这么做。如果你使用原生类型，你就失去了所有的安全性和泛型表达的好处。既然你不该去使用它们，为什么语言设计者一开始就允许使用原生类型？为了兼容。Java即将进入它的第二个十年，在这个时候加入泛型，已经存在了大量不使用泛型的代码。至关重要的是，所有这些代码都应该保持合法，并可以与使用泛型的更新的代码可以互相操作。将参数化类型的实例传递给设计与用于原始类型的方法必须是合法的，反之亦然。这一需求，即迁移兼容性，推动了支持原生类型以及使用类型擦除实现泛型的决策（item28 ）。

  虽然你不该使用原生类型比如List，但是可以使用参数化的类型以允许插入任意对象，比如List