为什么 Google Collections 不像 Apache Collections 那样支持 MultiKeyMap？答案

【问题标题】：Why doesn't Google Collections support MultiKeyMap like Apache Collections?为什么 Google Collections 不像 Apache Collections 那样支持 MultiKeyMap？
【发布时间】：2011-01-23 06:51:49
【问题描述】：

Google 的决定是否与 SortedMultiSet (stackoverflow question) 的决定相似还是因为没有使用MultiKeyMap？

我知道MultiKeyMap 的替代方法可以是使用自定义类作为键，其中包含多个键作为其类成员。相反，我喜欢在调用MultiKeyMap的get时指定多个键的概念。

Apache 的MultiKeyMap 版本很棒，但我严重缺少泛型，因此研究了谷歌集合以获取它的现代实现。如果有人知道为什么 Google 还不支持它，或者有更好的替代方案，请回复。

【问题讨论】：

标签： java collections guava apache-commons

【解决方案1】：

仅供参考，接受的答案已在 2010 年 3 月得到答复，但截至 2010 年 9 月，Guava 包括 Table。

【讨论】：

您可以使用您在此处提供的更新信息编辑接受的答案吗？
@MonisIqbal 你不应该那样做。这是one post among many on Meta on this topic。如果您不喜欢接受的答案，请投反对票。如果您喜欢我的，请点赞，这就是按钮的用途。但是您不应该完全按内容编辑他人的答案，因为编辑功能是为了在不改变内容的情况下进行改进。

【解决方案2】：

我们有一个很好的两层映射实现，我们称之为“表”（K1 是“行键”，K2 是“列键”），但我们还没有发布它然而。但是，过去的两个键是收益递减的。

【讨论】：

很高兴有官方的 google-collection 人员回复 :) 我可以先了解一下这个“表”数据结构吗？为什么没有 3 层和 4 层地图？
@kevin-bourrillion 这张 2 层地图发布了吗？
是的，正如这里最受好评的答案所指出的那样。我的回答应该不被接受。
我知道我迟到了，但你能解释一下为什么“虽然过去的两个键是收益递减。”吗？

【解决方案3】：

我认为泛型可能是这里实施的亮点。如果你只看 Map 接口，就会有键类型 (K) 和值类型 (V) 的通用说明符。我不相信在不将实现分成多个类（每个关键组件一个）的情况下，使用泛型轻松指定它是不可能的。

每个人都需要一个类：

MultiKeyMap2<K1,K2,V>
MultiKeyMap3<K1,K2,K3,V>
MultiKeyMap4<K1,K2,K3,K4,V>
MultiKeyMap5<K1,K2,K3,K4,K5,V>

底层实现基本上是按照您的建议进行（使用自定义类）。但是，它并没有正式为它创建一个类，所有内容都是内联的。这确实是一个实现细节。但是要使用 Google 集合来执行相同的操作，自定义类的操作方式与我确定实现 hashCode() 和 equals() 的方式大致相同。

【讨论】：