Comments 17
1. equals и hashCode
Баян, конечно. Но раз спрашивают везде, давайте по-честному — и без карикатур на джуна.
🟢 Джун обычно отвечает уверенно и правильно:
equals— это равенство по значению,==— по ссылке; переопределилequals— переопредели иhashCode, это контракт; равные объекты обязаны вернуть равныйhashCode. Генерю через IDE, Lombok или беруrecord. Нормальный ответ, он правда так знает.🟡 Мидл показывает, что будет, если контракт нарушить. Переопределили только
equals— и два «равных» объекта дадут разныйhashCode, улетят в разные бакетыHashMap, аget()по второму ключу вернётnull, хотя элемент в карте лежит. Обратное контрактом не требуется: одинаковый хэш у разных объектов это просто коллизия, и это нормально. Сюда же правило, которое экономит нервы:hashCodeнельзя строить на полях, которые потом меняются.🔴 Сеньор говорит не про новые факты, а про то, как это спроектировать, чтобы не рвануло в реальном приложении. JPA-сущности:
idгенерит база, до сохранения онnull, и наивныйequalsпоidведёт detached- и managed-объекты по-разному —Setначинает «терять» элементы между сессиями. Лечится бизнес-ключом или фиксированнымhashCode. Плюс ловушка с Hibernate: ленивый прокси подменяет класс объекта, поэтомуequalsчерезgetClass()ломается на прокси, и берутinstanceof. Вот эта прод-боль и отличает сеньора, а не знание самого контракта.
Нормальный сеньор дает на простой вопрос - простой ответ. Если я спросил про equals и hashCode а кандидата начинает нести куда то в JPA и Hibernate хотя я даже не спрашивал его про это, значит что он мне зубы заговаривает а это на любом собесе или экзамене признак неуверенности.
как человек, который 10 лет на галерах отдал c# (не java, но без разницы) - если меня спросят про equals и hashCode, я отвечу вот так: "это что-то для сравнения объектов". всё. спросят, что там куда ломается, а когда не работает - в душе не читаю; никогда не сталкивался. столкнусь - за 5 минут изучу и сделаю правильно.
У меня в университете был один препод, который именно так и говорил - на экзамене на конкретный вопрос я ожидаю конкретный ответ. Это может быть одно предложение, иногда даже одно слово. Если вы заходите издалека - я расцениваю это не как широкие знания, а как забалтывание незнания.
Проблемы гибернейта - это проблемы гибернейта. Вообще для POJO явно расписывать иквалс - это моветон. Проще пальцы отломать у тех, кто такое пишет. Не надо этого для JPA, проще надо быть.
Ну в принципе вся статья про то, почему ожидания на современных собеседованиях бывают абсолютно неадекватные.
Зачем мне лезть и рассказывать детали чего-либо, если меня про них не спросили? Почему я должен угадывать, что ждёт интервьюер? Это совсем не тот навык, который нужен и используется в реальной работе
Если бы меня спросили несколько лет назад, на какую позицию такие вопросы можно задавать, я бы выше мидла бы не назвал. А сейчас сениору задают - очевидно, сениор девальвировался.
"Дают код, где сто потоков по тысяче раз дёргают один счётчик, и спрашивают, будет ли в конце 100000. " - это вопрос-ловушка data race vs synchronization.
По теории, сначала разрабатываем корректность, потом измеряем производительность, и только после измерений - правим оверхед. Если где-то нашли узкое место - его и расширяем.
А вообще ИМХО статья про то, что можно и до столба приколебаться, и вообще интервьюеры имели в виду какие-то свои метрики при постановке вопросов :)
Особенно прекрасно в этом вопросе, предполагаемый ответ джуна “нет, будет меньше”. А почему, собственно, не рассматривается вариант “мне повезёт”, и будет именно столько, сколько ожидается?
Ведь именно этот вариант и является причиной багов на проде. А если сразу получаем неправильное значение, то даже юнит-тесты это отловят.
Жаль что подобные посты нельзя банить и удалять, делая Хабр чише. Какой-то уникум найдёт это через поиск и реально будет продвигать это на собесах. А потом все бегают с тезисами "Найм сломал. Во всем виноваты HR".
Хоть это больше и реклама, спасибо за труд.
Но вы почему-то делаете из сеньора какого-то зазнайку. Он по вашему постоянно съезжает с темы, начинает погружаться туда, куда не просили и действительно, как написано выше в комментах, забалтывать вопрос.
И не смотря на то что в статье действительно много полезных фактов в целом она не несет какой-то ценности для любого грейда кроме понимания - "Если сеньор такой - то я не сеньор"
Optional<List<T>>— нонсенс, пустой список и так говорит «ничего нет»
"Значениий нет" в списке и "списка нет" вообще - разная семантика.
Не умеют джависты с СУБД работать, судя по детским вопросам про индекс на сеньорском уровне. И все теребят свою хэшмапу, как святую корову. Не учатся некоторые и учится не хотят.
8 вопросов с java-собеса в банке: Junior отвечает за 10 секунд, Senior — за 3 минуты. Кого берут?