优先考虑类型安全的异构容器

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

考虑一个例子，你须要提供某种应用程序的上下文，它能够将特定的键绑定到任意类型的值。利用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都进行绑定是合理的。

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）。可是运行下面的代码将使咱们重返现实，由于咱们仍将在最后一行赋值语句处跌入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 ); 
复制代码

哪里出问题了呢？
首先，Context.get中的向下转型是无效的，由于类型擦除会使用静态转型的Object来代替无界参数（unbonded parameters）。此外更重要的是，这个实现根本就没有用到由Context.put提供的类型信息。这充其量是画蛇添足的美容罢了。
静态转型

Object obj; // may be an integer
if (obj instanceof Integer) {
    Integer objAsInt = (Integer) obj;
    // do something with 'objAsInt'
}
复制代码

这里使用了 instanceof 和转型操做符，这些操做符已经融入到语言当中了。对象转换的类型（这个例子中是Integer）必须是在编译期静态肯定的，因此咱们将这种转型称为静态转型。

类型安全的异构容器

虽然上面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）。

Paste_Image.png

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项）。

给出上述闭幕词，也没有什么要补充的了，除了祝愿你成功混合苹果和梨……
转自：www.importnew.com/15556.html

做者：KubiL 连接：https://www.jianshu.com/p/ce236d684bd6 來源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。