Почему бы не позволить внешнему интерфейсу предоставлять хэш-код/равняться HashMap?

. СЕТЬ имеет это через IEqualityComparer (для типа, который может сравнить два объекта), и IEquatable (для типа, который может сравнить себя с другим экземпляром).

На самом деле, я полагаю, что это была ошибка определить равенство и хэш-коды в java.lang. Объект или Система. Объект вообще. Равенство в особенности трудно определить способом, который имеет смысл с наследованием. Я продолжаю означать вести блог об этом...

, Но да, в основном идея является звуковой.

Примечание: Как отмечено во всех других ответах, HashMaps не имеют явного упорядочивания. Они только распознают "равенство". Вытаскивание порядка из основанной на хеше структуры данных бессмысленно, поскольку каждый объект превращен в хеш - по существу случайное число.

можно всегда писать хеш-функцию для класса (и часто времена должны), пока Вы делаете это тщательно. Это - твердая вещь сделать правильно, потому что основанные на хеше структуры данных полагаются на случайное, равномерное распределение значений хэш-функции. В Эффективном Java существует большая сумма текста, посвященного надлежащей реализации метода хеша с хорошим поведением.

Со всем, что, будучи сказанным, если Вы просто хотите, чтобы Ваше хеширование игнорировало регистр String, можно записать классу обертки приблизительно String с этой целью и ввести тех, которые в структуре данных вместо этого.

А простая реализация:

public class LowerStringWrapper {
    public LowerStringWrapper(String s) {
        this.s = s;
        this.lowerString = s.toLowerString();
    }

    // getter methods omitted

    // Rely on the hashing of String, as we know it to be good.
    public int hashCode() { return lowerString.hashCode(); }

    // We overrode hashCode, so we MUST also override equals. It is required
    // that if a.equals(b), then a.hashCode() == b.hashCode(), so we must
    // restore that invariant.
    public boolean equals(Object obj) {
        if (obj instanceof LowerStringWrapper) {
            return lowerString.equals(((LowerStringWrapper)obj).lowerString;
        } else {
            return lowerString.equals(obj);
        }
    }

    private String s;
    private String lowerString;
}

хороший вопрос, попросите перебрасываться шутками блоховский. я утверждал, что понятие как RFE в java 7, но это было отброшено, я полагаю, что причина была чем-то связанная производительность. я соглашаюсь, тем не менее, должен был быть сделан.

Я подозреваю, что это не было сделано, потому что это предотвратит кэширование хэш-кода?

я делал попытку создания универсального решения для Карты, где все ключи тихо перенесены. Оказалось, что обертка должна будет содержать перенесенный объект, кэшируемый хэш-код и ссылку на интерфейс обратного вызова, ответственный за проверки равенства. Это, очевидно, не столь эффективно как использование класса обертки, где необходимо было бы только кэшировать исходный ключ плюс еще один объект (см. ответ hazzens).

(я также врезался в проблему, связанную с дженериками; получать-метод принимает Объект как вход, таким образом, интерфейс обратного вызова, ответственный за хеширование, должен был бы выполнить дополнительную instanceof-проверку. Или это или класс сопоставления должно было бы знать Класс его ключей.)

Это - интересная идея, но это является абсолютно ужасающим для производительности. Причина этого довольно фундаментальна для идея хеш-таблицы : на упорядочивание нельзя положиться. Хеш-таблицы очень быстры ( постоянное время ) из-за пути, которым они индексируют элементы в таблице: путем вычислений псевдоуникального целочисленного хеша для того элемента и доступа к тому местоположению в массиве. Это буквально вычисляет местоположение в памяти и непосредственно хранит элемент.

Это контрастирует со сбалансированным деревом двоичного поиска (TreeMap), который должен запуститься в корне и проложить себе путь вниз к желаемому узлу каждый раз, когда поиск требуется. Википедия имеет еще приблизительно глубокий анализ . Подводя итоги, эффективность древовидной карты зависит от последовательного упорядочивания, таким образом порядок элементов предсказуем и нормален. Однако из-за хита производительности, наложенного "пересечением к Вашему целевому" подходу, BSTs только могут обеспечить O (журнал (n)) производительность. Для больших карт это может быть значительным хитом производительности.

возможно наложить последовательное упорядочивание на хеш-таблицу, но сделать так включает методы использования, подобные LinkedHashMap и вручную поддержание упорядочивания. С другой стороны, две отдельных структуры данных могут сохраняться внутренне: хеш-таблица и дерево. Таблица может использоваться для поисков, в то время как дерево может использоваться для повторения. Проблема, конечно, это использует, более чем удваивают необходимую память. Кроме того, вставки только с такой скоростью, как дерево: O (журнал (n)). Параллельные приемы могут снизить это немного, но это не надежная оптимизация производительности.

Короче говоря, Ваша идея звуки действительно хороший, но если бы Вы на самом деле пытались реализовать его, Вы видели бы, что сделать так наложило бы крупные ограничения производительности. Окончательный вердикт (и был в течение многих десятилетий): при необходимости в производительности используйте хеш-таблицу; если Вы нуждаетесь в упорядочивании и можете жить с ухудшенной производительностью, используйте сбалансированное дерево двоичного поиска. Я боюсь, что существует действительно не эффективно объединение этих двух структур, не теряя некоторые гарантии одной или другого.