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

Question

谷歌的决定是类似于SortedMultiSet (stackoverflow question)的决定，还是因为没有使用MultiKeyMap

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

阿帕奇的MultiKeyMap版本很棒，但我严重缺乏泛型，因此我在Google Collections中寻找它的现代实现。如果有人知道为什么Google还没有支持它，或者有更好的替代方案，请回复。

Answer 1

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

Answer 2

仅供参考，公认的答案是在2010年3月回答的，但截至2010年9月，Guava包含Table。

• Collections explained - Table
• Tables utility class
• Table javadoc

Answer 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>

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