Что ж, если вы посмотрите на источник HashSet
, вы увидите, что это в основном HashMap<E, Object>
с элементами, являющимися ключами - и изменение ключей hashmap никогда не было бы хорошей идеей. Карта / набор не будет обновляться, если хэш изменится, фактически карта / набор даже не будет знать об этом изменении.
В общем случае ключи HashMap или элементы вHashSet должен быть неизменным в том смысле, что их хэш и равенство не меняются. В большинстве случаев хэш и равенство основаны на идентичности этого (бизнес) объекта, поэтому, если number
и string
являются частью идентификатора этого объекта, вы не сможете их изменить.
Модификация объекта, который где-то содержится в наборе (возможно, даже не зная), кажется мне обычным вариантом использования. И кое-что, что я, вероятно, уже много сделал.
Вероятно, правда, что объекты, содержащиеся в наборах, изменяются довольно часто, но обычно это означает, что данные, которые не используются для генерации хеш-кода или проверки равенствамодифицированы. В качестве примера, скажем, хэш-код человека основан на его идентификационном номере. Это означало бы, что hashCode()
и equals()
должны основываться только на этом числе и что все остальное можно безопасно изменять.
Таким образом, вы можете изменять элементы в HashSet, если вы не изменяете их"id".
Когда или почему я должен использовать HashSet, если он имеет такое поведение?
Если вам нужно хранить изменяемые объекты в HashSet, у вас естьНесколько вариантов, которые в основном вращаются вокруг использования только неизменяемых частей для hashCode()
и equals()
. Для наборов, которые могут быть выполнены с использованием объекта-оболочки, который предоставляет настраиваемую реализацию для этих методов. В качестве альтернативы вы можете извлечь одно или несколько неизменяемых свойств и использовать их в качестве ключа на карте (в случае нескольких свойств вам потребуется создать какой-то ключевой объект из них)