Как правильно генерировать ключи для HashMap и какого типа?
Есть ли какой-то общепринятый способ генерирования ключей и какими они должны быть? Пока генерирую целочисленные ключи, очередной ключ - инкремент предыдущего. Жду ссылок на ресурсы, обоснованных ответов.
О чем вопрос, о java.util.Hashmap или о хешмап вообще? Если о первом, то она сама все генерирует. Как именно - достаточно заглянуть в исходник, в котором, заодно, подробно документировано, почему именно так и какие проблемы это решает.
Если вообще - то и ответ можно дать только общий: любым способом, подходящим для поставленных задач :)
И, да... "инкремент предыдущего" - это не хеширование.
pi314:
1) хеширование инкапсулировано в HashMap, сам я не хеширую, а генерирую КЛЮЧИ для хеширования;
2) метод put класса HashMap однозначно требует 2 параметра. сигнатура такова: put(K key, V value);
koi com: Ну, Мап - это, вообще-то, структура данных для отображения множества ключей на множество значений. Если ключей в задаче нет (их приходится генерировать), то, вероятно, разумнее взять список, например, ArrayList, а не создавать искуственно проблему, которую потом героически решать :)
pi314:
1) сударь вы несете полную чушь
2) пытаетесь казаться умным.
3) очевидно, что map это СД что дальше?
4) HashMap это совсем не мап, а hash table based implementation of the Map interface.
5) отсылаете к документации а сами даже не прочитали что такое HashMap в java
6) не делайте предположений
7) отвечайте конкретно по вопросу, "задачу" оставьте мне
8) HashMap нужен мне для быстрого доступа к элементу (учите таблицы с хешированем, хотя вы наверное и это "знаете"), вместо сканирования ArrayList
koi com: Если вы все знаете - зачем спрашиваете? :) (И тем более оскорбляете собеседника)
Ну вот к примеру нагенерировали вы ключей. (Потратили процессорное время на их генерацию). Потом их нужно где-то хранить - где? И не потратите ли вы опять таки ресурсы на получение этих ключей из структуры , в которой они хранятся? Все таки Map используется в случаях . когда ключ уже существует. Генерировать ключи ради того чтобы они были никто не станет. Например некий уникальный id обьекта в базе данных или url или к примеру id DOM-элемента или же некий индекс в существующем списке.
По поводу общепринятых канонов - лично я не встречал пока. Пихают туда все подряд. В зависмости от ситуации.
koi com: Спасибо, поржал от души :) Продолжайте в том же духе, и очень скоро вас ждет множество удивительных открытий относительно структур данных, одним из которых станет мучительное осознание абсолютной бессмысленности заданного вопроса и идеи генерации ключей только для того, чтоб они были. Учитывая разыгравшуюся бурю пронумерованных страстей, было бы просто негуманно лишать вас удовольствия сделать их самостоятельно.
pi314: Задача вполне обычная, надо хранить список объектов и доставать их по ключу.
Ключ задача не ограничивает. Обычно берут поле ID из хранимых объектов.
Так вот, что использовать в качестве ключа (читай поля ID в объекте) обычно и вызывает проблемы в начале.
Можно ведь по разному извратиться. Строка, число, UUID и т.д.
Так что посмейтесь над своей дислексией, из-за невозможности прочитать и понять вопрос...
Solver: Это, безусловно, любопытная и весьма творческая интерпретация вопроса... только, если ключи все-таки по логике задачи есть, то может возникнуть вопрос, который выбрать (Long, String и т.д.), а не как сгенерировать дополнительный. Опять же, возникнуть он может у тех, кому лень сделать лишний клик и заглянуть в имплементацию HashMap.
Только вот этого всего (вероятно, благодаря дислексии) я в вопросе не нашел, а нашел искуственные целочисленные ключи, которые, видимо, полностью удовлетворяют логике задачи. В этом месте остается только недоумевать, почему тогда не использовать массив и не получать объекты по... та-дам: тому же самому целочисленному индексу :) Это - принципиально быстрее и экономнее по памяти, чем любые хеши-меши. Более того, если ключ искуственный (сгенерированный), напрашивается следующий и, собственно, основной вопрос философии: а на кой он вообще нужен?! Если он сохраняется в каком-то отдельном от коллекции месте, почему не сохранить там... та-дам: поинтер на объект? Ну и, наконец, если, не взирая на здравый смысл, все же очень хочется ну хоть какой-нибудь хеш (ибо лишний поиск по дереву - это стильно, модно, молодежно), то почему бы просто не взять... та-дам: хеш самого объекта? Если бы автор читал предложения до конца, а не до того места, где желание нахамить становится нестерпимым, он бы заглянул в имплементацию той самой Мэп, которой он меня стращает, и увидел бы, что она именно так и поступает, дополнительно выравнивая дисперсию младших бит. Выражаясь проще, ей АБСОЛЮТНО ФИОЛЕТОВО, что там в ключе и даже какого он типа - она берет хеш объекта.
В сухом остатке приходим к печальному выводу: либо реальный ключ по логике задачи таки есть (и тогда его нужно просто использовать; который - полностью зависит от логики задачи), либо его нет, и тогда нефиг смешить людей и городить какие-то Мэпы там, где нужно использовать Лист, или, возможно, даже Сет. Вот в какие дебри могут увести домыслы и спекуляции... А, между тем, автор недвусмысленно уточнил: 6) не делайте предположений, и 7) отвечайте конкретно по вопросу, "задачу" оставьте мне.
Так что, думаю, наиболее разумное в сложившейся ситуации, это просто последовать этим мудрым заповедям и разойтись смеяться - каждый о своем :)
pi314: Во первых, ключ в любом случае сгенерирован. Не появляются они сами по себе, они не могут просто быть, нет там магии никакой. И в начале всегда встает такой вопрос, что лучше использовать для ключа.
И кстати, где в вопросе было про "дополнительный" ключ?
А во вторых, расскажите как сохранить в отдельном месте, например в БД или внешнем сервисе, поинтер на объект.
В общем не надо ничего искать в вопросе, не надо уходить в дебри и спекулировать на ровном месте... это же не философская доктрина)) надо просто прочитать вопрос.
"Как правильно генерировать ключи для HashMap и какого типа?"
Где Вы там видите хоть слово про БД, внешний сервис или что-то похожее? В контексте БД или даже ORM вопрос просто не может возникнуть (если, конечно не заниматься костылестроением), т.к. за его решение там отвечает sequence / автоинкремент / композитный ключ / соотв. аннотация JPA... это все - вещи, никак не связанные с HashMap, а полностью вытекающие из логики задачи.
Если не начинать фантазировать, то вопрос из области банального знания (точнее, незнания) явовского collection framework, и касается конкретно ключей в Map. Вот и вся нехитрая философская доктрина :)
P.S. "Дополнительный" в данном случае просто синоним "сгенерированный", и означает, что какие-то данные создаются программой искусственно, а не вытекают из логики задачи / алгоритма / не вводятся в программу извне. Ваши аргументы были бы абсолютно справедливы в контексте БД, но, как я уже указал, этим в вопросе даже не пахнет.
А как господа-генераторы собираются доставать значения из мапы когда исходный ключ будет потерян (GC, область видимости, передача мапы как аргумента)? pi314 однозначно истолковал проблему - незачем генерировать ключи на всякий случай, используйте существующие (или вообще откажитесь от ассоциативного массива). Короче оверинжиниринг от непонимания.
Ключем в HashMap может быть что угодно (и даже NULL) В качестве ключа HashMap использует результат метода Object.hashCode(). По этому поводу у Блоха очень хорошо написано, почитайте
Простой
