Java泛型映射不同的值类型详解及实例代码

java泛型映射不同的值类型详解

前言：

一般来说，开发人员偶尔会遇到这样的情形： 在一个特定容器中映射任意类型的值。然而java 集合api只提供了参数化的容器。这限制了类型安全地使用hashmap，如单一的值类型。但如果想混合苹果和梨，该怎样做呢？

幸运的是，有一个简单的设计模式允许使用java泛型映射不同的值类型，joshua bloch在其《effective java》（第二版，第29项）中将其描述为类型安全的异构容器（typesafe hetereogeneous container）。

关于这个主题，最近碰到一些不太合适的解决方案。它给了我在这篇文章中解释这个问题域，并阐述一些实现细节的想法。

使用java泛型映射不同的值类型

考虑一个例子，你需要提供某种应用程序的上下文，它可以将特定的键绑定到任意类型的值。利用string作为键的hashmap，一个简单的、非类型安全（type safe）的实现可能是这样的：

public class context {

 private final map<string,object> values = new hashmap<>();

 public void put( string key, object value ) {
  values.put( key, value );
 }

 public object get( string key ) {
  return values.get( key );
 }

 [...]
}

接下来的代码片段展示了怎样在程序中使用context ：

context context = new context();
runnable runnable = ...
context.put( "key", runnable );

// several computation cycles later...
runnable value = ( runnable )context.get( "key" );

可以看出，这种方法的缺点是在第6行需要进行向下转型（down cast）。如果替换键值对中值的类型，显然会抛出一个classcastexception异常:

context context = new context();
runnable runnable = ...
context.put( "key", runnable );

// several computation cycles later...
executor executor = ...
context.put( "key", executor );

// even more computation cycles later...
runnable value = ( runnable )context.get( "key" ); // runtime problem

产生这种问题的原因是很难被跟踪到的，因为相关的实现步骤可能已经广泛分布在你的程序各个部分中。

为了改善这种情况，貌似将value和它的key、它的value都进行绑定是合理的。

在我看到的、按照这种方法的多种解决方案中，常见的错误或多或少归结于下面context的变种：

public class context {

 private final <string, object> values = new hashmap<>();

 public <t> void put( string key, t value, class<t> valuetype ) {
  values.put( key, value );
 }

 public <t> t get( string key, class<t> valuetype ) {
  return ( t )values.get( key );
 }

 [...]
}

同样的基本用法可能是这样的：

context context = new context();
runnable runnable = ...
context.put( "key", runnable, runnable.class );

// several computation cycles later...
runnable value = context.get( "key", runnable.class );

乍一看，这段代码可能会给你更类型安全的错觉，因为其在第6行避免了向下转型（down cast）。但是运行下面的代码将使我们重返现实，因为我们仍将在第10行赋值语句处跌入classcastexception 的怀抱：

context context = new context();
runnable runnable = ...
context.put( "key", runnable, runnable.class );

// several computation cycles later...
executor executor = ...
context.put( "key", executor, executor.class );

// even more computation cycles later...
runnable value = context.get( "key", runnable.class ); // runtime problem

哪里出问题了呢？

首先，context#get中的向下转型是无效的，因为类型擦除会使用静态转型的object来代替*参数（unbonded parameters）。此外更重要的是，这个实现根本就没有用到由context#put 提供的类型信息。这充其量是多此一举的美容罢了。

类型安全的异构容器

虽然上面context 的变种不起作用，但却指明了方向。接下来的问题是：怎样合理地参数化这个key？ 为了回答这个问题，让我们先看看一个根据bloch所描述的类型安全异构容器模式（typesafe heterogenous container pattern）的简装实现吧。

我们的想法是用key自身的class 类型作为key。因为class 是参数化的类型，它可以确保我们使context方法是类型安全的，而无需诉诸于一个未经检查的强制转换为t。这种形式的一个class 对象称之为类型令牌（type token）。

public class context {

 private final map<class<?>, object> values = new hashmap<>();

 public <t> void put( class<t> key, t value ) {
  values.put( key, value );
 }

 public <t> t get( class<t> key ) {
  return key.cast( values.get( key ) );
 }

 [...]
}

请注意在context#get 的实现中是如何用一个有效的动态变量替换向下转型的。客户端可以这样使用这个context：

context context = new context();
runnable runnable ...
context.put( runnable.class, runnable );

// several computation cycles later...  
executor executor = ...
context.put( executor.class, executor );

// even more computation cycles later...
runnable value = context.get( runnable.class );

这次客户端的代码将可以正常工作，不再有类转换的问题，因为不可能通过一个不同的值类型来交换某个键值对。

有光明的地方就必然有阴影，有阴影的地方就必然有光明。不存在没有阴影的光明，也不存在没有光明的阴影。村上春树
bloch指出这种模式有两个局限性。“首先，恶意的客户端可以通过以原生态形式（raw form）使用class对象轻松地破坏类型安全。”为了确保在运行时类型安全可以在context#put中使用动态转换（dynamic cast）。

public <t> void put( class<t> key, t value ) {
 values.put( key, key.cast( value ) );
}

第二个局限在于它不能用在不可具体化（non-reifiable ）的类型中（见《effective java》第25项）。换句话说，你可以保存runnable 或runnable[]，但是不能保存list<runnable>。

这是因为list<runnable>没有特定class对象，所有的参数化类型指的是相同的list.class 对象。因此，bloch指出对于这种局限性没有满意的解决方案。

但是，假如你需要存储两个具有相同值类型的条目该怎么办呢？如果仅为了存入类型安全的容器，可以考虑创建新的类型扩展，但这显然不是最好的设计。使用定制的key也许是更好的方案。

多条同类型容器条目

为了能够存储多条同类型容器条目，我们可以用自定义key改变context 类。这种key必须提供我们类型安全所需的类型信息，以及区分不同的值对象（value objects）的标识。一个以string 实例为标识的、幼稚的key实现可能是这样的：

public class key<t> {

 final string identifier;
 final class<t> type;

 public key( string identifier, class<t> type ) {
  this.identifier = identifier;
  this.type = type;
 }
}

我们再次使用参数化的class作为类型信息的钩子，调整后的context将使用参数化的key而不是class。

public class context {

 private final map<key<?>, object> values = new hashmap<>();

 public <t> void put( key<t> key, t value ) {
  values.put( key, value );
 }

 public <t> t get( key<t> key ) {
  return key.type.cast( values.get( key ) );
 }

 [...]
}

客户端将这样使用这个版本的context：

context context = new context();

runnable runnable1 = ...
key<runnable> key1 = new key<>( "id1", runnable.class );
context.put( key1, runnable1 );

runnable runnable2 = ...
key<runnable> key2 = new key<>( "id2", runnable.class );
context.put( key2, runnable2 );

// several computation cycles later...
runnable actual = context.get( key1 );

assertthat( actual ).issameas( runnable1 );

虽然这个代码片段可用，但仍有缺陷。在context#get中，key被用作查询参数。用相同的identifier和class初始化两个不同的key的实例，一个用于put，另一个用于get，最后get操作将返回null 。这不是我们想要的……

//译者附代码片段
context context = new context();

runnable runnable1 = ...
key<runnable> key1 = new key<>( "same-id", runnable.class );
key<runnable> key2 = new key<>( "same-id", runnable.class );
context.put( key1, runnable1 );//一个用于put

context.get(key2); //另一个用于get --> return null;

幸运的是，为key设计合适的equals 和hashcode 可以轻松解决这个问题，进而使hashmap 查找按预期工作。最后，你可以为创建key提供一个工厂方法以简化其创建过程（与static import一起使用时有用）：

public static key key( string identifier, class type ) {
 return new key( identifier, type );
}

结论

“集合api说明了泛型的一般用法，限制你每个容器只能有固定数目的类型参数。你可以通过将类型参数放在键上而不是容器上来避开这个限制。对于这种类型安全的 异构容器，可以用class对应作为键。”（joshua bloch，《effective java》第29项）。

给出上述闭幕词，也没有什么要补充的了，除了祝愿你成功混合苹果和梨……

感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！