Java泛型映射不同的值类型详解及实例代码
Java泛型映射不同的值类型详解
前言：
一般来说，开发人员偶尔会遇到这样的情形：在一个特定容器中映射任意类型的值。然而Java集合API只提供了参数化的容器。这限制了类型安全地使用HashMap，如单一的值类型。但如果想混合苹果和梨，该怎样做呢？
幸运的是，有一个简单的设计模式允许使用Java泛型映射不同的值类型，JoshuaBloch在其《EffectiveJava》（第二版，第29项）中将其描述为类型安全的异构容器（typesafehetereogeneousContainer）。
关于这个主题，最近碰到一些不太合适的解决方案。它给了我在这篇文章中解释这个问题域，并阐述一些实现细节的想法。
使用Java泛型映射不同的值类型
考虑一个例子，你需要提供某种应用程序的上下文，它可以将特定的键绑定到任意类型的值。利用String作为键的HashMap，一个简单的、非类型安全（typesafe）的实现可能是这样的：
publicclassContext{
privatefinalMap<String,Object>values=newHashMap<>();
publicvoidput(Stringkey,Objectvalue){
values.put(key,value);
}
publicObjectget(Stringkey){
returnvalues.get(key);
}
[...]
}
接下来的代码片段展示了怎样在程序中使用Context：
Contextcontext=newContext();
Runnablerunnable=...
context.put("key",runnable);
//severalcomputationcycleslater...
Runnablevalue=(Runnable)context.get("key");
可以看出，这种方法的缺点是在第6行需要进行向下转型（downcast）。如果替换键值对中值的类型，显然会抛出一个ClassCastException异常:
Contextcontext=newContext();
Runnablerunnable=...
context.put("key",runnable);
//severalcomputationcycleslater...
Executorexecutor=...
context.put("key",executor);
//evenmorecomputationcycleslater...
Runnablevalue=(Runnable)context.get("key");//runtimeproblem
产生这种问题的原因是很难被跟踪到的，因为相关的实现步骤可能已经广泛分布在你的程序各个部分中。
为了改善这种情况，貌似将value和它的key、它的value都进行绑定是合理的。
在我看到的、按照这种方法的多种解决方案中，常见的错误或多或少归结于下面Context的变种：
publicclassContext{
privatefinal<String,Object>values=newHashMap<>();
public<T>voidput(Stringkey,Tvalue,Class<T>valueType){
values.put(key,value);
}
public<T>Tget(Stringkey,Class<T>valueType){
return(T)values.get(key);
}
[...]
}
同样的基本用法可能是这样的：
Contextcontext=newContext();
Runnablerunnable=...
context.put("key",runnable,Runnable.class);
//severalcomputationcycleslater...
Runnablevalue=context.get("key",Runnable.class);
乍一看，这段代码可能会给你更类型安全的错觉，因为其在第6行避免了向下转型（downcast）。但是运行下面的代码将使我们重返现实，因为我们仍将在第10行赋值语句处跌入ClassCastException的怀抱：
Contextcontext=newContext();
Runnablerunnable=...
context.put("key",runnable,Runnable.class);
//severalcomputationcycleslater...
Executorexecutor=...
context.put("key",executor,Executor.class);
//evenmorecomputationcycleslater...
Runnablevalue=context.get("key",Runnable.class);//runtimeproblem
哪里出问题了呢？
首先，Context#get中的向下转型是无效的，因为类型擦除会使用静态转型的Object来代替无界参数（unbondedparameters）。此外更重要的是，这个实现根本就没有用到由Context#put提供的类型信息。这充其量是多此一举的美容罢了。
类型安全的异构容器
虽然上面Context的变种不起作用，但却指明了方向。接下来的问题是：怎样合理地参数化这个key？为了回答这个问题，让我们先看看一个根据Bloch所描述的类型安全异构容器模式（typesafeheterogenouscontainerpattern）的简装实现吧。
我们的想法是用key自身的class类型作为key。因为Class是参数化的类型，它可以确保我们使Context方法是类型安全的，而无需诉诸于一个未经检查的强制转换为T。这种形式的一个Class对象称之为类型令牌（typetoken）。
publicclassContext{
privatefinalMap<Class<?>,Object>values=newHashMap<>();
public<T>voidput(Class<T>key,Tvalue){
values.put(key,value);
}
public<T>Tget(Class<T>key){
returnkey.cast(values.get(key));
}
[...]
}
请注意在Context#get的实现中是如何用一个有效的动态变量替换向下转型的。客户端可以这样使用这个context：
Contextcontext=newContext(); Runnablerunnable... context.put(Runnable.class,runnable); //severalcomputationcycleslater... Executorexecutor=... context.put(Executor.class,executor); //evenmorecomputationcycleslater... Runnablevalue=context.get(Runnable.class);
这次客户端的代码将可以正常工作，不再有类转换的问题，因为不可能通过一个不同的值类型来交换某个键值对。
有光明的地方就必然有阴影，有阴影的地方就必然有光明。不存在没有阴影的光明，也不存在没有光明的阴影。村上春树
Bloch指出这种模式有两个局限性。“首先，恶意的客户端可以通过以原生态形式（rawform）使用class对象轻松地破坏类型安全。”为了确保在运行时类型安全可以在Context#put中使用动态转换（dynamiccast）。
public<T>voidput(Class<T>key,Tvalue){
values.put(key,key.cast(value));
}
第二个局限在于它不能用在不可具体化（non-reifiable）的类型中（见《EffectiveJava》第25项）。换句话说，你可以保存Runnable或Runnable[]，但是不能保存List<Runnable>。
这是因为List<Runnable>没有特定class对象，所有的参数化类型指的是相同的List.class对象。因此，Bloch指出对于这种局限性没有满意的解决方案。
但是，假如你需要存储两个具有相同值类型的条目该怎么办呢？如果仅为了存入类型安全的容器，可以考虑创建新的类型扩展，但这显然不是最好的设计。使用定制的Key也许是更好的方案。
多条同类型容器条目
为了能够存储多条同类型容器条目，我们可以用自定义key改变Context类。这种key必须提供我们类型安全所需的类型信息，以及区分不同的值对象（valueobjects）的标识。一个以String实例为标识的、幼稚的key实现可能是这样的：
publicclassKey<T>{
finalStringidentifier;
finalClass<T>type;
publicKey(Stringidentifier,Class<T>type){
this.identifier=identifier;
this.type=type;
}
}
我们再次使用参数化的Class作为类型信息的钩子，调整后的Context将使用参数化的Key而不是Class。
publicclassContext{
privatefinalMap<Key<?>,Object>values=newHashMap<>();
public<T>voidput(Key<T>key,Tvalue){
values.put(key,value);
}
public<T>Tget(Key<T>key){
returnkey.type.cast(values.get(key));
}
[...]
}
客户端将这样使用这个版本的Context：
Contextcontext=newContext();
Runnablerunnable1=...
Key<Runnable>key1=newKey<>("id1",Runnable.class);
context.put(key1,runnable1);
Runnablerunnable2=...
Key<Runnable>key2=newKey<>("id2",Runnable.class);
context.put(key2,runnable2);
//severalcomputationcycleslater...
Runnableactual=context.get(key1);
assertThat(actual).isSameAs(runnable1);
虽然这个代码片段可用，但仍有缺陷。在Context#get中，Key被用作查询参数。用相同的identifier和class初始化两个不同的Key的实例，一个用于put，另一个用于get，最后get操作将返回null。这不是我们想要的……
//译者附代码片段
Contextcontext=newContext();
Runnablerunnable1=...
Key<Runnable>key1=newKey<>("same-id",Runnable.class);
Key<Runnable>key2=newKey<>("same-id",Runnable.class);
context.put(key1,runnable1);//一个用于put
context.get(key2);//另一个用于get-->returnnull;
幸运的是，为Key设计合适的equals和hashCode可以轻松解决这个问题，进而使HashMap查找按预期工作。最后，你可以为创建key提供一个工厂方法以简化其创建过程（与staticimport一起使用时有用）：
publicstaticKeykey(Stringidentifier,Classtype){
returnnewKey(identifier,type);
}
结论
“集合API说明了泛型的一般用法，限制你每个容器只能有固定数目的类型参数。你可以通过将类型参数放在键上而不是容器上来避开这个限制。对于这种类型安全的异构容器，可以用Class对应作为键。”（JoshuaBloch，《EffectiveJava》第29项）。
给出上述闭幕词，也没有什么要补充的了，除了祝愿你成功混合苹果和梨……
感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！