Я полагаю, вы должны реализовать такую карту самостоятельно.Вы правы, что это должно быть отсортировано;реализация get
должна будет перебирать ключи до тех пор, пока не найдет самый большой ключ, который меньше или равен аргументу.
Если вы подклассом TreeMap
, первоначально может показаться, что вы можете получитьработая через простое переопределение get()
метода.Однако, чтобы сохранить как можно большую часть контракта Map, вам придется переопределить другие методы для согласованности.
А как насчет, например, containsKey()
?Содержит ли ваша основная карта для 40
?Если вы вернете false
, клиент может принять решение не звонить get()
на основании этой информации;по этой причине (и формальному определению) вы должны вернуть true
.Но тогда становится трудно определить, действительно ли карта «содержит» данное отображение;если вы хотите что-то сделать, например обновить, не перезаписывая ничего, что уже существует.
Метод remove()
также может быть сложным.Из моего прочтения интерфейса,
// Calling map.remove "Removes the mapping for a key from this map if it is present."
map.remove(x);
// Now that the mapping is removed, I believe the following must hold
assert map.get(x) == null;
assert map.containsKey(x);
Действовать последовательно здесь было бы очень сложно.Если у вас есть сопоставление от 35-40, например, и вы звоните remove(38)
, то, насколько я понимаю, вам придется вернуть null
для любого последующего получения ключа 38, но вернуть вышеупомянутое сопоставление для ключей 35-37 или 39-40.
Таким образом, хотя вы можете начать с переопределения TreeMap, возможно, концепция Map
не совсем то, что вам нужно.Если вам не нужно это поведение для вставки в существующие методы, которые принимают Map
, может быть проще создать его самостоятельно как отдельный класс, поскольку это не вполне Карта, как вы ее определяете.