Почему вместо аннотации @Autowired рекомендуют использовать конструктор?

Question

[ceramicthree]

Недавно начал изучать Spring и стало интересно почему комьюнити и само IDE рекоммендует не использовать @Autowired
Чем такой код:

private final EmployeeRepository repository;

EmployeeController(EmployeeRepository repository) {
    this.repository = repository;
  }

лучше этого:

@Autowired
private EmployeeRepository repository;

Answer 1

[Jacen11]

типа при тестировании. Когда тест будешь писать не забудешь подставить объекты. А так особо без разницы вроде

Comments

[Орхан Гасанлы]

Разница использования DI имеется. Подробно можно прочитать в Spring in action.

[Jacen11]

azerphoenix, а поконкретнее? я если честно книгу не осилил. А по этому вопросу только с коллегами общался. Причем меня интересует не то, что там под капотом разные вещи делаются, это понятно. В чем по вашему практическая разница?

[Орхан Гасанлы]

Jacen11,

Это насчет того, почему Autowired необязательна

Самая интересная особенность аннотации @Autowired состоит в
том, что ее необязательно применять к методу записи. Эту аннота-
цию можно применить к любому методу, чтобы обеспечить автома-
тическое внедрение ссылки на компонент

Тут ответ насчет того, почему должен быть один конструктор с аннотацией @Autowired

В действительности существуют несколько обстоятельств, меша-
ющих работе аннотации @Autowired . В частности, должен существо-
вать точно один компонент, подходящий для связывания со свой-
ством или параметром, аннотированным с помощью @Autowired . Если
имеется несколько подходящих компонентов или нет ни одного, ан-
нотация @Autowired столкнется с определенными проблемами.

В книге далее дается подробное описание...

Насчет разницы в property, setter & constructor:
https://stackoverflow.com/questions/33562731/sprin...
https://www.javacodegeeks.com/2019/02/field-setter...
https://www.logicbig.com/tutorials/spring-framewor...

Если честно, то книга очень понравилась. Правда, не успел еще дочитать до конца...

[Jacen11]

azerphoenix, эм. Не столкнется, насколько я помню если есть бины с одинаковым типом возьмется первый попавшийся и в том числе в конструктор. Это проблема не автовайред, а инжекции в спринге в принципе. А вообще если есть необходимость сделать чтобы были бины с одинаковыми типами то там можно прописать им индефикацию(квалифаернейм вроде) и в инжекции прописывать с каким именем вставлять.

Вы хоть сами то читали, что написано в ссылках? Там же банальщина по типу "если не в конструктор, то много много полей будет некрасиво"

[Орхан Гасанлы]

Jacen11, да там по ссылкам честно говоря, бред. Описание в книге мне понравилось больше. Но сейчас лень копаться в ней))) DI в книге посвящена целая глава, где описаны преимущества и недостатки.

[Jacen11]

azerphoenix, мы знаем в чем плюсы депенси инжекшен. Нас интересует вопрос почему конструктор лучше по вашему мнению. Свою версию я высказал. Жду вашу)

[Орхан Гасанлы]

Jacen11, нуу, если я правильно понял преимущества конструктора, то она заключается в том, что он гарантирует готовность объекта и не внедрит объект пока зависимость не будет готова.

[Jacen11]

azerphoenix, нет там такого. Фабрика делает объекты и отдает их, что для конструктора, что для поля одинаково. Скоуп можно настроить чтобы объект делался по запросу и отдавался каждый раз новый, но по умолчанию там вообще синглтон.

внедрит объект пока зависимость не будет готова.

не понимаю что это вообще такое и как может быть.

[Иван Луполов]

Как по мне между внедрением через конструктор и сеттер есть существенная разница. С помощью конструктора можно скрыть не изменяемые атрибуты класса, сеттер этого не обеспечит, поэтому в подобных случаях он не подходит. Но у внедрения через конструктор, есть проблема, он может породить циклическую зависимость, чего нет при использовании сеттера. Также циклическую зависимость при инжекции в конструкторе можно исправить с помощью аннотации @Lazy перед параметром, который вызывает зависимость. Эти способы применяются для разных задач. А инжекции в поле я вообще не люблю, т.е. идёт как бы нарушение инкапсуляции, у тебя есть приватное поле, которое не сетится ни в конструкторе, ни методе, но значение туда записываются.

Answer 2

[Орхан Гасанлы]

Я и сам изучаю пока что Spring.
Прежде всего рекомендую прочитать книгу Spring in action. Там описаны все возможности DI и их преимущества.
1 - DI property

@Autowired
private SomeClass someClass

2 - DI setter
3 - DI constructor

@Autowired
private final SomeClass someClass;
SomeService (SomeClass someClass) {
this.someClass = someClass;
}

Насчет использования аннотации @Autowired
Использование этой аннотации необязательно в принципе. Но если например для класса имеется несколько конструкторов, то нужно для одного из них добавить аннотацию.

Я например, в своих pet проектах использую так:

@RequiredArgsConstructor
public class PageController {
private final SomeClass1 someClass1;
private final SomeClass2 someClass2;
private final SomeClass3 someClass3;
}

Т.е. подключаю lombok и использую DI конструктором...

Comments

[Jacen11]

@RequiredArgsConstructor

никакого отношения к инжекциям или спрингу это не имеет, это просто аннотация которая нагенерит код с проверками на налабл и кинет эксепшин если что то оказалось равным нулю. Нахрена вам эта аннотация если потом все равно будет ошибка когда произойдет обращение к этому объекту? А если нет обращения к этому объекту, то зачем он нужен?

[Орхан Гасанлы]

Jacen11,
причем тут @RequiredArgsConstructorи Spring.
Я ниже написал, что это lombok. И да, это не имеет отношения к DI.

Т.е. подключаю lombok и использую DI конструктором...

В pet проектах я его использую лишь для читабельности и не более.
Насчет использования конструктора, в данном случае я имею ввиду это:

The IoC container makes sure that all the arguments provided in the constructor are available before passing them into the constructor. This helps in preventing the infamous NullPointerException.

Another difference between setter vs constructor injection in Spring and one of the drawbacks of setter injection is that it does not ensures dependency Injection. You can not guarantee that certain dependency is injected or not, which means you may have an object with incomplete dependency. On the other hand, constructor Injection does not allow you to construct an object until your dependencies are ready.

https://javarevisited.blogspot.com/2012/11/differe...

Answer 3

[Иван Луполов]

Как по мне между внедрением через конструктор и сеттер есть существенная разница. С помощью конструктора можно скрыть не изменяемые атрибуты класса, сеттер этого не обеспечит, поэтому в подобных случаях он не подходит. Но у внедрения через конструктор, есть проблема, он может породить циклическую зависимость, чего нет при использовании сеттера. Также циклическую зависимость при инжекции в конструкторе можно исправить с помощью аннотации @Lazy перед параметром, который вызывает зависимость. Эти способы применяются для разных задач. А инжекции в поле я вообще не люблю, т.е. идёт как бы нарушение инкапсуляции, у тебя есть приватное поле, которое не сетится ни в конструкторе, ни методе, но значение туда записываются.

Answer 4

[Евгений Краснов]

На сколько я помню, из документации, то Spring говорит - если есть возможно, то, лучше не использовать аннотация и вообще привязываться жёстко к Spring-у не хорошая идея. Что то в этом духе как бы так. Ну и если логично подумать, например, произошло какое то обновление с этими аннотациями, то ваше приложение сломается, а если будут конструкторы, менее вероятно что ваше приложение сломается. Ну в общем как то так мой юный друг.