当前位置：文江博客话题详情

Map.get(Object key) 不（完全）通用的原因是什么

发布于 2024-12-02 08:15:09 字数 380 浏览 1 评论 0 原文

决定不使用完全通用的 get 方法的原因是什么在接口中java.util.Map。

为了澄清问题，该方法的签名是

V get(Object key)

而不是

V get(K key)

我想知道为什么（对于 V get(Object key) 也是如此）代码>删除，包含键，包含值）。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

忆梦 2024-12-09 08:15:10

我认为泛型教程的这一部分解释了这种情况（我的重点）：

“您需要确保泛型 API 没有过度限制；它必须
继续支持API原有合约。再考虑一些例子
来自 java.util.Collection。预泛型 API 看起来像：

interface Collection { 
  public boolean containsAll(Collection c);
  ...
}

一个天真的尝试将其泛化为：

interface Collection<E> { 
  public boolean containsAll(Collection<E> c);
  ...
}

虽然这确实是类型安全的，但它不符合 API 的原始约定。
containsAll() 方法适用于任何类型的传入集合。只会
如果传入集合确实只包含 E 的实例，则成功，但是：

传入集合的静态类型
收集可能会有所不同，也许
因为调用者不知道
集合的精确类型
传入，或者也许因为它是
集合，其中 S 是
E 的子类型，
非常完美
调用 containsAll() 是合法的
不同类型的集合。这
例程应该有效，返回 false。”

I think this section of Generics Tutorial explains the situation (my emphasis):

"You need to make certain that the generic API is not unduly restrictive; it must
continue to support the original contract of the API. Consider again some examples
from java.util.Collection. The pre-generic API looks like:

interface Collection { 
  public boolean containsAll(Collection c);
  ...
}

A naive attempt to generify it is:

interface Collection<E> { 
  public boolean containsAll(Collection<E> c);
  ...
}

While this is certainly type safe, it doesn’t live up to the API’s original contract.
The containsAll() method works with any kind of incoming collection. It will only
succeed if the incoming collection really contains only instances of E, but:

The static type of the incoming
collection might differ, perhaps
because the caller doesn’t know the
precise type of the collection being
passed in, or perhaps because it is a
Collection<S>,where S is a
subtype of E.
It’s perfectly
legitimate to call containsAll() with
a collection of a different type. The
routine should work, returning false."

回复收藏 0 原文

梦醒灬来后我 2024-12-09 08:15:10

兼容性。

在泛型可用之前，只有 get(Object o)。

如果他们将此方法更改为 get( o)，则可能会迫使 Java 用户进行大量代码维护，只是为了使工作代码再次编译。

他们可以引入一个附加方法，例如get_checked( o)并弃用旧的get()方法，以便有一个更温和的过渡路径。但由于某种原因，这并没有完成。（我们现在的情况是，您需要安装像 findBugs 这样的工具来检查 get() 参数和映射的声明键类型之间的类型兼容性。）

与 .equals 语义相关的参数我认为 () 是假的。（从技术上讲，它们是正确的，但我仍然认为它们是假的。如果 o1 和 o2 没有任何共同的超类，那么任何头脑正常的设计师都不会让 o1.equals(o2) 为真。）

回复收藏 0 原文

把人绕傻吧 2024-12-09 08:15:10

原因是遏制是由 equals 和 hashCode 确定的，它们是 Object 上的方法，并且都采用 Object 参数。这是 Java 标准库的早期设计缺陷。再加上 Java 类型系统的限制，它强制任何依赖 equals 和 hashCode 的东西都采用 Object。

在 Java 中拥有类型安全哈希表和相等性的唯一方法是避开 Object.equals 和 Object.hashCode 并使用通用替代品。 Functional Java 附带了用于此目的的类型类：哈希和等于 。 HashMap 的包装器 提供了在其中采用 Hash 和 Equal构造函数。因此，此类的 get 和 contains 方法采用 K 类型的泛型参数。

例子：

HashMap<String, Integer> h =
  new HashMap<String, Integer>(Equal.stringEqual, Hash.stringHash);

h.add("one", 1);

h.get("one"); // All good

h.get(Integer.valueOf(1)); // Compiler error

The reason is that containment is determined by equals and hashCode which are methods on Object and both take an Object parameter. This was an early design flaw in Java's standard libraries. Coupled with limitations in Java's type system, it forces anything that relies on equals and hashCode to take Object.

The only way to have type-safe hash tables and equality in Java is to eschew Object.equals and Object.hashCode and use a generic substitute. Functional Java comes with type classes for just this purpose: Hash<A> and Equal<A>. A wrapper for HashMap<K, V> is provided that takes Hash<K> and Equal<K> in its constructor. This class's get and contains methods therefore take a generic argument of type K.

Example:

HashMap<String, Integer> h =
  new HashMap<String, Integer>(Equal.stringEqual, Hash.stringHash);

h.add("one", 1);

h.get("one"); // All good

h.get(Integer.valueOf(1)); // Compiler error

回复收藏 0 原文

别挽留 2024-12-09 08:15:10

还有一个更重要的原因，它在技术上无法完成，因为它破坏了地图。

Java 具有多态泛型结构，如。标记的此类引用可以指向用签名的类型。但多态泛型使该引用成为只读。编译器允许您仅使用泛型类型作为方法的返回类型（如简单的 getter），但会阻止使用泛型类型为参数的方法（如普通的 setter）。
这意味着如果你写 Map，编译器不允许你调用方法get()，这样映射就没有用了。唯一的解决方案是使该方法不再通用：get(Object)。

回复收藏 0 原文

梦魇绽荼蘼 2024-12-09 08:15:10

我猜是向后兼容。 Map（或HashMap）仍然需要支持get(Object)。

回复收藏 0 原文

↙温凉少女 2024-12-09 08:15:10

我看着这个并思考他们为什么这样做。我认为现有的任何答案都不能解释为什么他们不能让新的通用接口仅接受正确的密钥类型。真正的原因是，即使他们引入了泛型，他们也没有创建新的接口。 Map 接口与旧的非通用 Map 相同，它只是充当通用和非通用版本。这样，如果您有一个接受非通用 Map 的方法，您可以向它传递一个 Map 并且它仍然可以工作。同时 get 的契约接受 Object，因此新接口也应该支持这个契约。

在我看来，他们应该添加一个新接口并在现有集合上实现这两个接口，但他们决定支持兼容接口，即使这意味着 get 方法的设计更糟糕。请注意，集合本身与现有方法兼容，只有接口不兼容。

回复收藏 0 原文

空心空情空意 2024-12-09 08:15:10

我们刚刚正在进行大规模重构，我们错过了这个强类型的 get() 来检查我们是否错过了一些旧类型的 get() 。

但我发现了编译时间检查的解决方法/丑陋技巧：使用强类型 get、containsKey、remove... 创建 Map 接口，并将其放入项目的 java.util 包中。

你会得到编译错误只是为了调用 get()，...使用错误的类型，其他一切对于编译器来说似乎都可以（至少在 eclipse kepler 内）。

检查构建后不要忘记删除此接口，因为这不是您在运行时想要的。

回复收藏 0 原文

趁年轻赶紧闹 2024-12-09 08:15:09

正如其他人所提到的， get() 等之所以不通用，是因为您要检索的条目的键不必与您传递给 < 的对象具有相同的类型。代码>get();该方法的规范仅要求它们相等。这是从 equals() 方法如何接受一个对象作为参数得出的，而不仅仅是与对象相同的类型。

虽然许多类都定义了 equals() ，因此它的对象只能等于它自己类的对象，但在 Java 中很多地方情况并非如此。例如，List.equals() 的规范规定，如果两个 List 对象都是列表并且具有相同的内容，则它们相等，即使它们是 List 的不同实现>。因此，回到这个问题中的示例，根据方法的规范，可以有一个 Map 并让我调用 get()以 LinkedList 作为参数，它应该检索具有相同内容的列表的键。如果 get() 是通用的并且限制其参数类型，则这是不可能的。