TG Telegram Group & Channel
Java: fill the gaps | United States America (US)
Create: Update:

Загадка Set.of🔮

В прошлом посте обсуждали toList, в этом обсудим Set.of. Здесь ситуация сложнее и гораздо интереснее! Прекрасный пример для тренировки анализа и критического мышления.

Начнем с ответа: код с Set.of выбросит IllegalArgumentException(duplicate element: 2)

Неожиданно! Set - коллекция уникальных элементов. Мы привыкли, что сет сам фильтрует дубликаты и часто это используем.

Почему теперь сет ругается на дубликаты? Почему фильтрацию по уникальности должен делать разработчик перед вставкой?

Но это ещё не всё. Если убрать дубликаты и оставить код таким:
Set.of(1, 2, null)

получим NPE Cannot invoke "Object.hashCode()" because "pe" is null. Какая-то ошибка внутри реализации🤯

Поищем ответ в документации, точнее в JEP. Set.of появился в java 9, его цель обозначена явно - создать удобную альтернативу ручному заполнению сета:

// 8
Set<String> set = new HashSet<>();
set.add("a");
set.add("b");
set = Collections.unmodifiableSet(set);
// 9
Set<String>set = Set.of(“a“, “b“);

Удобно, конечно, но альтернатива получилась не равнозначная.
Почему новый код не умеет фильтровать дубликаты? Почему не умеет работать с null? Почему “удобная” версия работает по-другому?

Я с джавой работаю давно, поэтому причину знаю и расскажу вам в следующем посте. А пока давайте оценим единственную версию из интернета:

🧔 Элементы задаются все и сразу, программист их видит. Если передаются дубликаты или null - это точно ошибка разработчика.

Здесь можно потренировать критическое мышление и подумать, что не так с этой версией.

А потом прочитать 3 причины:

Не всегда значения наглядно записаны. Их могут передать через конструктор или через поля обьекта:
Set<Long> adminIds = Set.of(user1.getId(), user2.getId());

Бросать исключение в рантайме при подозрении на опечатку как-то слишком брутально

Если мы не считаем null нормальным элементом, почему не отфильтровать его в начале? Почему мы видим NPE из глубин реализации?

Итого, вариант “чтобы разработчик был внимательнее” нам не подходит. Причина в чем-то другом.

Оставлю вас подумать над этим, а в следующем посте расскажу, почему Set.of такой странный. Там интересно😊

Загадка Set.of🔮

В прошлом посте обсуждали toList, в этом обсудим Set.of. Здесь ситуация сложнее и гораздо интереснее! Прекрасный пример для тренировки анализа и критического мышления.

Начнем с ответа: код с Set.of выбросит IllegalArgumentException(duplicate element: 2)

Неожиданно! Set - коллекция уникальных элементов. Мы привыкли, что сет сам фильтрует дубликаты и часто это используем.

Почему теперь сет ругается на дубликаты? Почему фильтрацию по уникальности должен делать разработчик перед вставкой?

Но это ещё не всё. Если убрать дубликаты и оставить код таким:
Set.of(1, 2, null)

получим NPE Cannot invoke "Object.hashCode()" because "pe" is null. Какая-то ошибка внутри реализации🤯

Поищем ответ в документации, точнее в JEP. Set.of появился в java 9, его цель обозначена явно - создать удобную альтернативу ручному заполнению сета:
// 8
Set<String> set = new HashSet<>();
set.add("a");
set.add("b");
set = Collections.unmodifiableSet(set);
// 9
Set<String>set = Set.of(“a“, “b“);

Удобно, конечно, но альтернатива получилась не равнозначная.
Почему новый код не умеет фильтровать дубликаты? Почему не умеет работать с null? Почему “удобная” версия работает по-другому?

Я с джавой работаю давно, поэтому причину знаю и расскажу вам в следующем посте. А пока давайте оценим единственную версию из интернета:

🧔 Элементы задаются все и сразу, программист их видит. Если передаются дубликаты или null - это точно ошибка разработчика.

Здесь можно потренировать критическое мышление и подумать, что не так с этой версией.

А потом прочитать 3 причины:

Не всегда значения наглядно записаны. Их могут передать через конструктор или через поля обьекта:
Set<Long> adminIds = Set.of(user1.getId(), user2.getId());

Бросать исключение в рантайме при подозрении на опечатку как-то слишком брутально

Если мы не считаем null нормальным элементом, почему не отфильтровать его в начале? Почему мы видим NPE из глубин реализации?

Итого, вариант “чтобы разработчик был внимательнее” нам не подходит. Причина в чем-то другом.

Оставлю вас подумать над этим, а в следующем посте расскажу, почему Set.of такой странный. Там интересно😊


>>Click here to continue<<

Java: fill the gaps




Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)