Почему Google Collections не поддерживает MultiKeyMap как Наборы Apache?
Решение Google, подобного тому для SortedMultiSet (stackoverflow вопрос), или это, потому что там нет смысла MultiKeyMap?
Я знаю что альтернатива для MultiKeyMap может быть должен использовать пользовательский Класс в качестве ключа, который содержит несколько ключей как его участников класса. Наоборот, мне нравится понятие определения нескольких ключей при вызове получения MultiKeyMap.
Версия Apache MultiKeyMap является большим, но я сильно пропускаю Дженерики и поэтому изучил Google Collections для современной реализации его. Если у кого-то есть какая-либо идея, почему Google еще не поддерживал ее или существует лучшая альтернатива для нее, затем ответьте.
2 ответа
У нас есть очень хорошая реализация двухуровневой карты, которую мы называем «таблицей» (K1 - это «ключ строки», а K2 - «ключ столбца»), и мы просто еще не выпустили ее. еще. Однако последние два ключа - это убывающая отдача.
Я думаю, что дженерики могут стать здесь ограничителем для реализации. Если вы посмотрите только на интерфейс 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().