JA @java_fillthegaps
Showing posts older than #213 · Back to latest
git push --force.
switch (user.getState()) {
case NEW: …
case CONFIRMED: …
case BANNED: … }
Switch - это не просто набор нескольких if. У объекта user 3 статуса. Список чётко определен, статусы не пересекаются между собой.switch (animal) {
case Cat c → c.putToBox();
case Dog d → d.train(); }
Итак, в чём разница между switch в 2000 и switch в 2021?❌ for(int i=0;i<100;i++)3️⃣ Перенести код в отдельный метод
✅ for(int i=0;i<HLIMIT;i++)
class FileLogger {…}
class Service {
FileLogger logger=new FileLogger();
}
Сделаем код чуть лучше:class Service {
FileLogger logger;
Service (FileLogger logger) {
this.logger= logger;
}
}
✅ Класс не занимается инициализацией логгераinterface Logger {…}
class FileLogger implements Logger {…}
class Service {
Logger logger=new FileLogger();
}
✅ В интерфейсе доступно меньше методов, поэтому его проще использовать@Component class FileLogger {…}
@Component class Service {
@Autowired
FileLogger logger;
}
✅ Меньше скучного кодаclass ServiceLocator {
private static Logger logger=…
public static Logger getLogger() {
return logger;
}
}
public class Service {
private Logger logger = ServiceLocator.getLogger();
}
Резюме:
collect(toMap(Student::id, Student::name)) collect(toMap(Student::city,["Москва":"Антон Аня Эдуард"]
Student::name,
(a,b) -> a+" "+b))
Map<String, List<Student>>=…По умолчанию сгруппированные элементы объединяются в список. Чтобы получить что-нибудь другое, передайте в метод другой коллектор:
collect(groupingBy (Student::city))
groupingBy(Student::city, toSet())Здесь нам наконец пригодятся коллекторы из предыдущего поста, которые подставим во второй аргумент.
groupingBy(Student::city, counting())▫️Города и имена студентов:
groupingBy(Student::city,Передаём в groupingBy функцию для ключей и коллектор mapping для значений. Он же принимает другой коллектор toSet, чтобы было понятно, куда складывать результат.
mapping(Student::name, toSet()))
toMap(Student::id,Вместо расчёт() - километр кода. Подсчёт среднего недоступен в интерфейсе Stream, а удобных методов перевода List<Integer> в IntStream нет.
s -> s.marks().stream().расчёт())
Map<Boolean,Set<Student>>…Вместо toSet можно подставить другой коллектор. Посчитаем количество студентов:
partitioningBy(s-> s.city().equals("Moscow"), toSet())
partitioningBy(s-> s.city().equals("Moscow"), counting())
Не очень понятно, зачем нужен partitioningBy. groupingBy даёт такой же результат, но на 2 символа короче:groupingBy(s-> s.city().equals("Moscow"), counting())
❓Ответ на вопрос перед постом
list.stream()
2️⃣ .filter(e -> e != 3)
3️⃣ .count();
Терминальная операция collect собирает элементы стрима в другую структуру данных. Все подробности передаются через аргумент:collect(Collector collector) Set res=students.stream()Ещё одна группа - коллекторы, которые возвращают одно значение:
.filter(…).collect(toSet())
chars.stream().collect(joining("-"));
// ['a','b','c'] → a-b-c
🔸summarizingIntlist.stream().collect(counting())Коллекторы mapping, flatMapping и filtering применяют функцию к элементам перед отправкой в другой коллектор.
// аналог
list.stream().count()
Set<Long> ids = …Использовать их напрямую тоже смысла нет. Проще применить к элементам map, flatmap или filter, а потом собрать результаты:
collect(mapping(Student::id, toSet())
map(Student::id).collect(toSet())❓Зачем нужны эти методы?
synchronized (lock) {
return coll.remove(object);
}
Изменения последовательны, данные в безопасности и всегда актуальны. synchronized (lock) {
return coll.removeIf(filter);
}
Проблема в том, что такие ошибки сложно обнаружить. Default метод появился в марте 2014, а класс обновили в июле 2019. 5 лет пользователи SynchronizedCollection пользовались ненадёжным методом.