为什么Collections.checkedMap和朋友不常用？ [英] Why aren't Collections.checkedMap and friends used more commonly?

问题描述

我最近偶然发现了用于创建标准集合类型的动态类型安全视图的 Collection.checkedMap 函数系列的Javadoc。考虑到他们在集合之上添加了另一层安全，诊断相对常见的程序员错误，我想他们会更受欢迎。因为某种原因，在所有的大型Java项目中，我没有见过他们使用过一次。

我的问题是：一个特别的原因，Java程序员不使用这些检查包装更频繁？

编辑：为了澄清我的问题，集合的泛型版本仍然包含类型不安全的函数。 地图的 containsKey ， containsValue ， remove 和 get 都操作 Object 。我的主要问题是，鉴于这种类型的不安全，为什么更多的人不使用检查的实现来诊断运行时类型违规。

解决方案

这些类只有在滥用（或不使用）泛型时才真正需要。它在运行时检查应该足以在编译时通过泛型引擎的类型安全性保证来执行。

因此，使用这些方法只是真的很有趣在不信任库的用户的API设计者的上下文中，并且希望保护他们自己或用户不正确地使用映射的用户。

这里的短缺：如果你的代码编译没有原始类型警告或任何未检查的转换/类型警告，你是 ， checked * 方法不给你任何好处;

您似乎是结束了。 因为 remove ， get 等操作在 Object ，他们是不知何故类型不安全。他们不是。这些方法都不会将其操作数存储在映射中，因此您肯定不会损害映射本身的类型安全性。这些方法采取一个对象的一个​​主要原因：为向后兼容性。从来没有任何严格的要求，查找需要坚持同一个类。例如，如果类A的实例和类B的实例可以以某种方式彼此相等，将 a 插入到映射中，然后调用删除（b） 应删除 a 的映射。

在添加泛型后，需要支持此行为以保留向后兼容性。因此，它们不能将接口更新为类似 remove（K）的接口，因为现有代码可能依赖于能够移除给定完全不同类的实例的映射。然而，它不是类型不安全，并且使用检查版本的地图不会改变这种行为在丝毫。

I recently stumbled across the Javadoc for the Collection.checkedMap family of functions for creating dynamically typesafe views of the standard Collections types. Considering that they add another layer of safety on top of the collections that diagnoses a relatively common programmer error, I would have figured that they would be more popular. For some reason, though, in all of the large Java projects I've worked on, I've not seen them used once.

My question is this: is there a particular reason that Java programmers don't use these checked wrappers more frequently? Or is it just lack of benefit/lack of knowledge of their existence?

EDIT: To clarify my question, the generic versions of the collections still contain type-unsafe functions. Map's containsKey, containsValue, remove, and get all operate on Object, for example. My main question is, given this type-unsafety, why more people don't use the checked implementations to diagnose runtime type violations.

解决方案

These classes are only really necessary if one is abusing (or not using) generics. It duplicates at runtime checks that should be sufficient to perform at compile time through the type safety guarantees by the generics engine.

As a result, using these methods is only really interesting in the context of API designers who don't trust the users of the library, and want to protect either themselves, or the users, from the users using the map improperly.

Here's the short of it: if your code compiles without raw type warnings or any unchecked conversion/type warnings, you are guaranteed that the checked* methods don't give you any benefit; they are only a runtime hit.

Edit

You seem to be concluding that since remove, get, etc operate on an Object, they are somehow type-unsafe. They are not. None of those methods will store its operand in the map, so you are certainly not compromising the type safety of the map itself. Those methods take an Object for one main reason: for backwards compatibility. There was never any strict requirement that look-ups needed to adhere to the same class. For example, if an instance of class A and an instance of class B could somehow be equal to each other, putting a into the map and then calling remove(b) should remove a's mapping.

This behaviour needed to be supported once generics were added to preserve backwards compatibility. Thus they couldn't update the interface to something like remove(K) as existing code may rely on being able to remove a mapping given an instance of a completely different class. It is however not type unsafe, and using the checked version of the map doesn't change this behaviour in the slightest.

这篇关于为什么Collections.checkedMap和朋友不常用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！