Инжектя интерфейс мы завязываемся на абстракции. Таким образом, мы можем в любой момент заменить реализацию без изменения вызывающего класса. Также это один из принципов SOLID(который D).
Может быть полезно для подстановки мок реализаций в тестах например.
Вообще это довольно распространённый вопрос, стоит ли создавать интерфейсы если есть только одна реализация. С точки зрения правильности дизайна и чистоты кода наверное да, но часто можно обойтись и без них( в том числе и в этой статье), тут уже на вкус и цвет.
Не спорю, данный вариант тоже подходит, но суть архитектуры в том, что она завязана на дженериках и трансферах, а в случае, который советует Блох получается сильная привязка к enum — у, чего мне совсем не хотелось, т к данное поле изначально не являлось обязательным для бизнес логики.
Вы были правы на счёт даты. Вывод в логи тоже добавил.
Выбирать всех пользователей и потом фильтровать их это дурной тон. Представьте, что у вас миллионы пользователей. Вы их начнете втаскивать в память из базы.
А что вы предлагаете?
Разберите Exception e на несколько тех что реально бросаются, чтобы не подавлять RuntimeException
Как именно я могу узнать все возможные исключения?
Что именно вы хотите сделать? Судя по вашему вопросу вы хотите указать email отправителя в EmailServiceImpl, что показано в примере, который я скинул в предыдущем комментарии. А если нет, то объясните подробнее
Многие пишут, что StringBuffer тут не нужен, хотя @Scheduled использует многопоточность. Я не являюсь экспертом в области потоков, поэтому может ли кто-то из высказавшихся привести аргументы, и я исправлю его StringBuilder?
Инжектя интерфейс мы завязываемся на абстракции. Таким образом, мы можем в любой момент заменить реализацию без изменения вызывающего класса. Также это один из принципов SOLID(который D).
Может быть полезно для подстановки мок реализаций в тестах например.
Вообще это довольно распространённый вопрос, стоит ли создавать интерфейсы если есть только одна реализация. С точки зрения правильности дизайна и чистоты кода наверное да, но часто можно обойтись и без них( в том числе и в этой статье), тут уже на вкус и цвет.
2. Компилятор ни на что не ругается, если убрать try/catch
А что вы предлагаете?
Как именно я могу узнать все возможные исключения?
Многие пишут, что StringBuffer тут не нужен, хотя @Scheduled использует многопоточность. Я не являюсь экспертом в области потоков, поэтому может ли кто-то из высказавшихся привести аргументы, и я исправлю его StringBuilder?
Вообще то нужен, это одна из спецификаций
Нам не нужен @EqualsAndHashcode и @AllArgsConstructor, которые есть в Data. Но нужен конструктор без аргументов.