Почему в Java нет интерфейса Hashable

Ответ 1

Главный аргумент мне кажется, что существует четко определенный default hashCode, который может быть рассчитан для любого объекта Java вместе с одинаково четко определенным equals. Просто нет веских оснований для отказа от этой функции от всех объектов, и, конечно, существует множество причин не, чтобы удержать ее. Так что это не проблема в моей книге.

Ответ 2

Этот вопрос заявляется как дубликат от другого, который спрашивает, почему нет интерфейса, который ведет себя как Comparator (в отличие от Comparable), но для хэширования..NET включает в себя такой интерфейс, который называется IEqualityComparer, и похоже, что Java тоже может. Как бы то ни было, если кто-то хочет, например, имеют сборку Java, например, отображает строки в другие объекты в нечувствительном к регистру (возможно, наиболее распространенное использование IEqualityComparer), нужно обернуть строки в объектах, методы которых hashCode и equals действуют на основе без учета регистра.

Я подозреваю, что большая проблема заключается в том, что, хотя интерфейс "equalComparer" может быть удобным, во многих случаях для эффективного тестирования отношения эквивалентности потребуется кэширование информации. Например, в то время как не зависящая от регистра строки функция хеширования может сделать только прописную копию переданной строки и вызвать hashCode на этом, было бы трудно избежать того, чтобы каждый запрос хэш-кода конкретной строки повторялся преобразование в верхний регистр и хеширование этого верхнего регистра. Напротив, объект "без учета регистра строки" может включать в себя поля для только строчной копии строки, которые затем должны быть созданы только один раз для экземпляра.

An EqualityComparer мог бы достичь разумной производительности, если бы он включал что-то вроде WeakHashMap<string,string> для преобразования необработанных строк в строки только верхнего регистра, но для такой конструкции требовались бы разные потоки для использования разных экземпляров EqualityComparer, несмотря на отсутствие внешнее видимое состояние, или же требуется блокировка блокировки и синхронизации производительности, даже в однопоточных сценариях.

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

Ответ 3

Какая польза от наличия интерфейса, который каждый объект реализует по-своему? Поскольку Object реализует его и должен быть хешируемым, он должен иметь implements Hashable в своем объявлении, и все остальные классы наследуют его, потому что это подклассы Object. Наличие интерфейса Hashable будет просто указывать очевидное.