参考自：importNew

我们的想法是用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 ）的类型中

换句话说，你可以保存Runnable 或Runnable[]，但是不能保存List<Runnable>。

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

多条同类型容器条目

为了能够存储多条同类型容器条目，我们可以用自定义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 );
}




Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生