避免在具有多种值类型的映射中进行未经检查的分配？

Posted 2023-03-31

【中文标题】避免在具有多种值类型的映射中进行未经检查的分配？

【英文标题】：Avoid unchecked assignment in a map with multiple value types?

【发布时间】：2014-03-17 23:41:14

【问题描述】：

我在 Java 7 中遇到警告问题：

Unchecked assignment: 'java.lang.Class' to 'java.lang.Class<T>'

我在下面的 get 函数中将它放在Class<T> type = typeMap.get(key); 行上。

基本上我在这里尝试做的是我想存储一堆未知类型的键/值对（但除了 null 之外，它们都是 Object 的后代），但不会丢失类型。所以我使用泛型创建了一个具有以下内容的类。它有两个映射（一个用于存储数据，一个用于存储类类型：

    private Map<String, Object>  dataMap = new HashMap<>();
    private Map<String, Class> typeMap = new HashMap<>();

    public  <T> void put(String key, T instance)
        dataMap.put(key, instance);
        if (instance == null)
            typeMap.put(key,null);
        
        else 
            typeMap.put(key, instance.getClass());
        
    

    public <T> T get(String key)
        Class<T> type = typeMap.get(key);
        if (type == null)
            return null;
        
        return type.cast(dataMap.get(key));
    

它运行得很好，但警告让我很烦。有什么方法可以让 Java 在不抱怨的情况下进行这种转换（除了压制它）？还是有更好的方法来完成我想做的事情？ Java 8 怎么样，因为我还没有机会深入研究它？

谢谢！

【问题讨论】：

演员表将不安全。抑制警告可能会让您感觉更好，但您的代码实际上并不安全。

你试过私有 Map> typeMap = new HashMap() 吗？

您知道地图中将使用的类型吗？还是您希望它包含任何类型？

【参考方案1】：

您所显示的内容不安全的原因是这个作业：

Class<T> type = typeMap.get(key);

T 不需要与从地图中检索到的Class 有任何关系。 T 总是从调用get 的周围上下文中推断出来的。例如，我可以执行以下调用序列：

// T is inferred from the arguments as String (which is fine)
example.put("k", "v");
// T is inferred from the return value target type as Integer
Integer i = example.get("k");

在get 方法中，String.class 可以从类型映射中正确检索，但未经检查地转换为Class<Integer>。对type.cast(...) 的调用不会抛出，因为从数据映射中检索到的值是String。 实际上发生了隐式检查转换，返回值，将其转换为Integer，并抛出ClassCastException。

这种奇怪的互动是由于type erasure。

---

因此，当我们在单个数据结构中存储多种类型时，有多种处理方法，具体取决于我们的需求。

1。如果没有办法执行它们，我们可以放弃编译检查。

在这里存储Class 在很大程度上是没有意义的，因为正如我上面所展示的，它不会执行有用的验证。所以我们可以按照以下思路重新设计地图：

class Example 
    private final Map<String, Object> m = new HashMap<>();

    void put(String k, Object v) 
        m.put(k, v);
    

    Object getExplicit(String k) 
        return m.get(k);
    

    @SuppressWarnings("unchecked")
    <T> T getImplicit(String k) 
        return (T) m.get(k);
    

getExplicit 和 getImplicit 做了类似的事情，但是：

String a = (String) example.getExplicit("k");
// the generic version allows an implicit cast to be made
// (this is essentially what you're already doing)
String b = example.getImplicit("k");

在这两种情况下，我们只是依靠自己作为程序员的意识来不犯错误。

抑制警告不一定是坏事，重要的是要了解它们的实际含义和含义。

2。将Class 传递给get，因此返回值必须有效。

这是我看到的典型做法。

class Example 
    private final Map<String, Object> m = new HashMap<>();

    void put(String k, Object v) 
        m.put(k, v);
    

    <T> T get(String k, Class<T> c) 
        Object v = m.get(k);
        return c.isInstance(v) ? c.cast(v) : null;
    


example.put("k", "v");
// returns "v"
String s = example.get("k", String.class);
// returns null
Double d = example.get("k", Double.class);

但是，当然，这意味着我们需要将两个参数传递给get。

3。参数化键。

这是一本小说，但更先进，它可能更方便，也可能不更方便。

class Example 
    private final Map<Key<?>, Object> m = new HashMap<>();

    <V> Key<V> put(String s, V v) 
        Key<V> k = new Key<>(s, v);
        put(k, v);
        return k;
    

    <V> void put(Key<V> k, V v) 
        m.put(k, v);
    

    <V> V get(Key<V> k) 
        Object v = m.get(k);
        return k.c.isInstance(v) ? k.c.cast(v) : null;
    

    static final class Key<V> 
        private final String k;
        private final Class<? extends V> c;

        @SuppressWarnings("unchecked")
        Key(String k, V v) 
            // this cast will always be safe unless
            // the outside world is doing something fishy
            // like using raw types
            this(k, (Class<? extends V>) v.getClass());
        

        Key(String k, Class<? extends V> c) 
            this.k = k;
            this.c = c;
        

        @Override
        public int hashCode() 
            return k.hashCode();
        

        @Override
        public boolean equals(Object o) 
            return (o instanceof Key<?>) && ((Key<?>) o).k.equals(k);
        
    

例如：

Key<Float> k = example.put("k", 1.0f);
// returns 1.0f
Float f = example.get(k);
// returns null
Double d = example.get(new Key<>("k", Double.class));

如果条目是已知的或可预测的，这可能是有意义的，因此我们可以有类似的东西：

final class Keys 
    private Keys() 
    static final Key<Foo> FOO = new Key<>("foo", Foo.class);
    static final Key<Bar> BAR = new Key<>("bar", Bar.class);

然后我们不必在检索完成的任何时候构造一个关键对象。这非常有效，特别是在为字符串类型的场景添加一些强类型时。

Foo foo = example.get(Keys.FOO);

4。没有地图可以放入任何类型的对象，请使用某种多态性。

如果可能且不太麻烦，这是一个不错的选择。如果使用不同类型的共同行为，请将其设为接口或超类，这样我们就不必使用强制转换。

一个简单的例子可能是这样的：

// bunch of stuff
Map<String, Object> map = ...;

// store some data
map.put("abc", 123L);
map.put("def", 456D);

// wait awhile
awhile();

// some time later, consume the data
// being particular about types
consumeLong((Long) map.remove("abc"));
consumeDouble((Double) map.remove("def"));

我们可以改为这样：

Map<String, Runnable> map = ...;

// store operations as well as data
// while we know what the types are
map.put("abc", () -> consumeLong(123L));
map.put("def", () -> consumeDouble(456D));

awhile();

// consume, but no longer particular about types
map.remove("abc").run();
map.remove("def").run();

【参考方案2】：

您正试图将Class 类型的元素分配给Class<T> 类型的变量。当然，这是一个未经检查的任务。您似乎正在实施异构地图。 Java（和任何其他强类型语言）无法以静态类型安全的方式表达映射的值类型。

这是因为元素类型仅在运行时才知道。期望编译器对未知的事物进行静态类型检查是要求太多了。编译器甚至无法进行合理的静态类型推断，因此期望它预测动态类型推断的未来确实有点牵强。