Божечки мои. Вот что я искал два дня. Столько литературы перечитал на просторах интернета и пересмотрел видео, что уже потерял веру в то, что хоть кто-то объяснил почему именно нужно менять хешкод. Обычно все пишут/говорят "чтобы джава правильно сравнивала по хешкоду" - но эта фраза не дает понимания того, в какой момент и как это повлияет на нашу программу. На самом деле за два дня и сам смог додуматься, но мне важно, чтобы кто-то из опытных программистов это подтвердил своими словами)
Хорошо рассказал, но почему не упомянул, что по умолчанию для object сравнение идёт по адресам ссылок объектов? поэтому то нам и надо переопределить equals, но ведь иногда надо сравнивать именно адреса. Переопределение hashcode необходимо когда объект будет участвовать в сравнениях где задействована эта функция, например в коллекциях - так более обще. Надо было упомянуть что Set не допускает дублирования, поэтому не добавился одинаковый элемент. Удивлен как много у тебя про Java, причём каждая тема достаточно подробно объснена - с меня подписка. Спасибо за контент.
Отлично объяснил, я еще читал что есть некий контракт, который говорит что если ты переопределяешь метод equals то ты должен также переопределить hashCode ну и равносильно если переопределяешь hashCode
Спасибо! Описанные здесь проблемы с перебором всех объектов коллекции будут очень хорошо проявляться с использованием Hibernate и прочего ORM-подобного при неправильном написании hashCode()
здравсвуйте. пришел сюда по ссылке... еще зеленый(учусь 3 месяц). не могу понять за счёт чего активизируется метод equals... выходит потому что мы просим вывести количество объектов из arraylist Set и он сразу смотрит автоматически hashcode, а потом уже если нашлись оба одинаковые hashcode активизирует метод equals?
Когда мы добавялем что-то в коллекцию, которая работает через хэш-код, сама коллекция спрашивает у добавляемого обхекта hashCode. Еще раз - мы добавляем в коллекцию методом add, а сама коллекция вызывает методы hashCode и equals у нашего объекта. Удачи :)
@@java8599 в задачке из степика есть в ТЗ вернуть из переопределенного метода хешкод переменную re из вызываемого объекта, Хз как правильно нужно было решать но я вернул return Double.hashCode(re) ; Ещё допишу если есть ошибка
@@emirlanabdullaev8864 Выглядит вполне досттойно. Если тип re Double, то наверно можно re.hashCode(). Если же тип элементаррный double, то вообще хорошо смотрится.
А что если переданный объект не является MyClass? Сначала нужно проверить на то, что объект является инстанцией нужного класса, а потом проверять на равенство полей. В противном случае, метод может выкидывать ClassCastException, что будет нарушать принцип подстановки Барбары Лисков.
@@java8599 не согласен - все должно быть по правилам, а то кто-то переопределит hashcode и скажет: "Ну, пожалуй и хватит, пора и меру знать". И оставит реализацию equals() без изменений. Нет такого понятия - мера. Если что-то нужно знать и использовать, то это нужно знать и потом использовать, без оглядки на то кому чего будет где видно.
Вот этот ваш лонг в конструкторе как песком по глазам. Зачем принимать лонг, потом преобразовывать его к инту в хэшкоде? Почему не сказано, что это относится к работе коллекций в основе которых лежит хэш таблица? Почему "проверки" не сделаны в тестовых классах, а в мэин навалом? Ну и куча какой то воды, не раскрывающей суть работы хэш таблицы. Не рассказано про бакеты, индексы, коллизии и связанные списки, про лоад фактор. Важность хэшкода проявляется когда понимаешь как работает хэш таблица. А из этого виде как то не очень понятно. 19:55 Хэшкод не сужает ничего. По хэшкоду расчитывается индекс бакета в который попадает обьект, а в нем уже идет поиск по иквелсу если там уже есть обьекты. И эти обьекты там хранятся в виде связанного списка, что в свою очередь затратно для поиска. Вот и все.
Вы рассказываете про реализацию HashMap, но не путайте контракт между equals и hashCode как идею и ее конкретное воплощение в HashMap. Кто Вам сказал, что только HashMap имеет исключительные права на использование этого контракта ?
@@java8599 причем тут HashMap? Это всего лишь одна из реализаций коллекции использующая хэш таблицу. А писал я именно про хэш таблицы. Читайте внимательней что я пишу и не перекручивайте.
@@java8599 по поводу БД. Не мешайте всё в кучу. У вас тут идет разговор про переопределение public int hashCode() для джавовских обджектов. А он возвращает инт как не крути и независимо от того, сколько у вас обьектов в БД и вообще сколько обьектов вы способны нагенерировать. И это напрямую относится к контракту меду хэшкодом и иквелсом. А именно это отднонаправленный контракт. Если a.equals(b)==true, то a.hashCode()==b.hashCode(), но не наоборот. Если a.hashCode()==b.hashCode(), то не обязательно a.equals(b)==true. В этом ключ к пониманию этого контракта. :) переписывал пару раз, что бы было боле наглядно.. чуть сам не запутался.
Вы другими словами сказали то же, что и я. Просто я концентрировался на контракте, как идее - НЕравенство хэшкодов однозначно говорит о том, что объекты НЕ равны. Как это использовать - личное дело каждого.
