建议：优先考虑类型安全的异构容器。

        泛型最常用于集合，如Set和Map，以及单元素的容器，如ThreadLocal和Atomic Reference。在这些用法中，他都充当被参数化了的容器。这样就限制你每个容器只能有固定数目的类型参数。一般来说，这种情况正是你想要的。一个Set只有一个类型参数，表示它的元素类型；一个Map有两个类型参数，表示他的键和值类型；诸如此类。

        但是，有时候你会需要更多的灵活性。例如，数据库行可以有任意多的列，如果能以类型安全的方式访问所有列就好了。幸运的是，有一种方法可以很容易地做到这一点。这种想法就是将键（key）进行参数化而不是将容器（container）参数化。然后将参数化的键提交给容器，来插入或者获取值。用泛型系统来确保值的类型与他的键相符。

        简单的示范一下这种方法：考虑Favorites类，它允许其客户端从任意数量的其他类中，保存并获取一个“最喜爱”的实例。Class对象充当参数化键的部分。之所以可以这样，是因为Class<T>。例如，String.class属于Class<String>类型，Integer.class属于Class<Integer>类型。当一个类的字面文字被用在方法中，来传达编译时和运行时的类型信息时，就被称作type token。

        Favorites类的API很简单。她看起来就像一个简单的map，除了键（而不是map）被参数化之外。客户端在设置和获取最新喜爱的实例时提交Class对象。下面就是这个API：

// Typesafe heterogeneous container pattern - API

public class Favorites {

    public <T> void putFavorite(Class<T> type , T instance);

    public <T> T getFavorite(Class<T> type);

}

        下面是一个示例程序，检验以下Favorites类，他保存、获取并打印一个最喜爱的String、Integer和Class实例：

 

// Typesafe heterogeneous container pattern - client

public static void main(String[] args) {

    Favorites f = new Favorites();

    f.putFavorite(String.class , "Java");

    f.putFavorite(Integer.class , 0xcafebabe);

    f.putFavorite(Class.class , Favorites.class);

    String favoriteString = f.getFavorite(String.class);

    int favoriteInteger = f.getFavorite(Integer.class);

    Class<?> favoriteClass = f.getFavorite(Class.class);

    System.out.print("%s %x %s%n" , favoriteString , favoriteInteger , favoriteClass.getName());

}

        正如所料，这段程序打印出的是Java cafebabe Favorites。

        Favorites实例是类型安全（typesafe）的：当你向它请求String的时候，他从来不会返回一个Integer给你。同时他也是异构的（heterogeneous）：不像普通的map，他的所有键都是不同类型的。因此，我们将Favorites称作类型安全的异构容器（typesafe heterogeneous container）。

        Favorites的实现小的出奇。它的完整实现如下：

// Typesafe heterogeneous container pattern - implementation

public class Favorites {

    private Map<Class<?> , Object> favorites = new HashMap<Class<?> , Object>();

    public <T> void putFavorite(Class<T> type , T instance) {

        if (type == null) throw new NullPointerException("Type is null");

        favorites.put(type , instance);

    }

    public <T> T getFavorite(Class<T> type) {

        return type.cast(favorites.get(type));

    }

}

        这里发生了一些微妙的事情。每个Favorites实例都得到一个称作favorites的私有Map<Class<?> , Object>的支持。你可能认为由于无限制通配符类型的关系，将不能把任何东西放进这个Map中，但事实正好相反。要注意的是通配符类型是嵌套的：他不是属于通配符类型的Map的类型，而是他的键的类型。由此可见，每个键都可以有一个不同的参数化类型：一个可以是Class<String>，接下来是Class<Integer>等等。异构是从这里来的。

        第二件要注意的事情是：favorites Map的值类型只是Object。换句话说，Map并不能保证键和值之间的类型关系，既不能保证每个值的类型都与键的类型相同。事实上，Java的类型系统还没有强大到足以表达这一点。但我们知道这是事实，并在获取favorite的时候利用这一点。

        putFavorite方法的实现很简单：它只是把（从指定的Class对象到指定favorite实例的）一个映射放到favorites中。如前所述，这是放弃了键和值之间的“类型联系”，因此无法知道这个值是键的一个实例。但是没关系，因为getFavorites方法能够并且的确重新建立了这种联系。

        getFavorite方法的实现比putFavorite的更难一些。它先从favorites映射中获得与指定Class对象相对应的值。这正是要返回的对象引用，但他的编译时类型是错误的。他的类型只是Object（favorites映射的值类型），我们需要返回一个T。因此，getFavorite方法的实现利用Class的cast方法，将对象引用动态地转换（dynamically cast）成了Class对象所表示的类型。

        cast方法是Java的cast操作符的动态模拟。它只检验他的参数是否为Class对象所表示的类型的实例。如果是，就返回参数；否则就抛出ClassCastException异常。我们知道，getFavorite中的cast调用永远不会抛出ClassCastException异常，并假设客户端代码正确无误的进行了编译。也就是说，我们知道favorites映射中的值会始终与键的类型相匹配。

        假设cast方法只返回他的参数，那他能为我们做什么呢？cast方法的签名充分利用了Class类被泛型化的这个事实。他的返回类型是Class对象的类型参数：

public class Class<T> {

    T cast(Object obj);

}

        这正是getFavorite方法所需要的，也正是让我们不必借助于未受检地转换成T就能确保Favorites类型安全的东西。

        Favorites类有两种局限性值得注意。首先，恶意的客户端可以很轻松地破坏Favorites实例的类型安全，只要以他的原生态形式（raw form）使用Class对象。但会造成客户端代码在编译时产生未受检的警告。这与一般的集合实现，如HashSet和HashMap并没有什么区别。你可以很容易地利用原生态类型HashSet将String放进HashSet<Integer>中。也就是说，如果愿意付出一点点代价，就可以拥有运行时类型安全。确保Favorites永远不违背他的类型约束条件的方式是，让putFavorite方法检验instance是否真的是type所表示的类型的实例。我们已经知道如何进行了，只要使用一个动态的转换：

// Achieving runtime type safety with a dynamic cast

public <T> void putFavorite(Class<T> type , T instance) {

    favorites.put(type , type.cast(instance));

}

        java.util.Collections中有一些集合包装类采用了同样的技巧。他们称作checkedSet、checkedList、checkedMap，诸如此类。除了一个集合（或映射）之外，他们的静态工厂还采用一个（或者两个）Class对象。静态工厂属于泛型方法，确保Class对象和集合的编译时类型相匹配。包装类给他们所封装的集合增加了具体化。例如，如果有人视图将Coin放进你的Collection<Stamp>，包装类就会在运行时抛出ClassCastException异常。用这些包装类在混有泛型和遗留代码的应用程序中追溯“谁把错误的类型元素添加到了集合中”很有帮助。

        Favorites类的第二种局限性在于它不能用在不可具体化的（non-reifiable）类型中。话句话说，你可以保存最喜爱的String或者String[]，但不能保存最喜欢的List<String>。如果试图保存最喜爱的List<String>，程序就不能进行编译。原因在于他无法为List<String>获得一个Class对象：List<String>.Class是个语法错误，这也是件好事。List<String>和List<Integer>共用一个Class对象，即List.class。如果从“字面（type literal）”上来看，List<String>.class和List<Integer>.class是合法的，并反悔了相同的对象引用，就会破坏Favorites对象的内部结构。

        对于第二种局限性，还没有完全令人满意的解决办法。有一种方法称作super type token，它在解决这一局限性方面做了很多努力，但是这种方法仍有他自身的局限性。

        Favorites使用的类型令牌（type token）是无限制的：getFavorite和putFavorite接受任何Class对象。有时候，可能需要限制那些可以传给方法的类型。这可以通过有限制的类型令牌（bounded type token）来实现，他只是一个类型令牌，利用有限制类型参数或者有限制通配符，来限制可以表示的类型。

        注解API广泛利用了有限制的类型令牌。例如，这是一个在运行时读取注解的方法。这个方法来自AnnotatedElement接口，他通过表示类、方法、域及其他程序元素的反射类型来实现：

public <T extends Annotation> T getAnnotation(Class<T> annotationType);

        参数annotationType是一个表示注解类型的有限制的类型令牌。如果元素有这种类型的注解，该方法就将他返回，如果没有，则返回null。被注解的元素本质上是个类型安全的异构容器容器的键属于注解类型。

        假设你有一个类型Class<?>的对象，并且想将他传给一个需要有限制的类型令牌的方法，例如getAnnotation。你可以将对象转换成Class<? extends Annotation>，但是这种转换是非受检的，因此会产生一条编译时警告。幸运的是，类Class提供了一个安全的执行这种转换的实例方法。该方法称作asSubclass，他将调用他的Class对象转换成用其参数表示的类的一个子类。如果转换成功，该方法返回他的参数；如果失败，则抛出ClassCastException异常。

        以下示范了如何利用asSubclass方法在编译时读取类型未知的注解。这个方法编译时没有出现错误或者警告：

// Use of asSubclass to safely cast to a bounded type token

static Annotation getAnnotation(AnnotatedElement element , String annotationTypeName) {

    Class<?> annotationType = null; // Unbounded type token

    try {

        annotationType = Class.forName(annotationTypeName);

    } catch (Exception ex) {

        throw new IllegalArgumentException(ex);

    }

    return element.getAnnotation(annotationType.asSubclass(Annotation.class));

}

        总而言之，集合API说明了泛型的一般用法，限制你每个容器只能有固定数目的类型参数。你可以通过将类型参数放在键上而不是容器上来避开这一限制。对于这种类型安全的异构容器，可以用Class对象作为键。以这种方式使用的Class对象称作类型令牌。你也可以使用定制的键类型。例如，用一个DatabaseRow类型表示一个数据库行（容器），用泛型Column<T>作为他的键。