優先考慮類型安全的異構容器

通常來講，開發人員偶爾會遇到這樣的情形： 在一個特定容器中映射任意類型的值。然而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 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。