В мире разработки Spring, особенно Spring Boot, аннотация @Autowired уже давно является основным средством внедрения зависимостей в bean-компоненты, управляемые Spring. Однако с развитием лучших практик Spring и появлением новых функций @Autowired больше не является рекомендуемым подходом для внедрения зависимостей. Этот сдвиг может удивить разработчиков, знакомых со старыми версиями Spring. Сегодня мы углубимся в то, почему @Autowired теряет популярность, альтернативы, которые рекомендует Spring, и то, как вы можете модернизировать код в Spring.
Что такое @Autowired?
Прежде чем мы обсудим, почему Spring больше не рекомендует @Autowired, давайте кратко рассмотрим, что он делает. @Autowired используется в Spring для внедрения зависимостей в класс. Его можно применять к полям, конструкторам и методам установки, позволяя Spring автоматически внедрять необходимый компонент при запуске вашего приложения.
Проблема с @Autowired
- Скрытые зависимости: при использовании @Autowired в полях зависимости внедряются «за кулисами», что может привести к скрытым зависимостям. Такая практика затрудняет понимание того, что необходимо классу для правильной работы, что усложняет тестирование и отладку.
- Проблемы иммутабельности: внедрение полей позволяет зависимостям быть изменяемыми, что упрощает классу возможность их изменения позже. Это снижает неизменяемость ваших компонентов, что может привести к ошибкам, которые трудно отследить.
- Сложность тестирования. Тестирование компонентов, которые полагаются на внедрение в полевых условиях, может оказаться сложной задачей. Поскольку зависимости не передаются через конструкторы, вам необходимо вручную имитировать или внедрять эти поля в вашу тестовую установку, что может привести к добавлению ненужного шаблонного кода.
- Внедрение на основе конструктора более чистое: при внедрении на основе конструктора зависимости явно объявляются в конструкторе, что дает понять, какие компоненты необходимы для работы класса. Такой подход делает класс более читабельным, его легче тестировать и повышает общую удобство сопровождения.
Почему Spring рекомендует внедрение конструктора
В последние годы команда Spring перешла к внедрению в конструктор как к предпочтительному способу внедрения зависимостей, отойдя от внедрения в поля с помощью @Autowired. Вот несколько причин, почему:
- Обязательные зависимости. Внедрение в конструктор заставляет вас предоставлять все необходимые зависимости при создании экземпляра класса. Это гарантирует, что класс всегда находится в допустимом состоянии со всеми необходимыми зависимостями, установленными во время создания.
- Иммутабельность. Внедрение в конструктор поощряет использование конечных полей, что обеспечивает неизменность. После внедрения зависимости ее нельзя изменить, что снижает риск случайного изменения и ошибок в коде.
- Улучшенная тестируемость: тестирование компонентов с помощью внедрения конструктора намного проще. Вы можете просто передать макетные зависимости непосредственно в конструктор в своих тестах, не полагаясь на внутреннюю проводку Spring.
- Нет необходимости в @Autowired: если класс имеет только один конструктор, Spring может автоматически внедрять его зависимости без необходимости использования аннотации @Autowired. Это упрощает код и уменьшает беспорядок в аннотациях.
Расцвет @RequiredArgsConstructor
Для классов, использующих внедрение конструктора, еще одним полезным инструментом является аннотация @RequiredArgsConstructor от Lombok. Эта аннотация автоматически генерирует конструктор с обязательными полями (т.е. помеченными как окончательные), что еще больше сокращает шаблонный код.
@Autowired по-прежнему полезен, но используйте его с умом
Важно отметить, что @Autowired не устарел и не полностью не рекомендуется Spring. Это по-прежнему полезно в определенных сценариях, таких как:
- Внедрение через сеттер. В некоторых случаях вам может потребоваться использовать внедрение через сеттер, когда зависимости не являются обязательными или когда вам необходимо внедрить значения после создания объекта. Однако использовать его следует умеренно и только при необходимости.
- Устаревший код. Если вы работаете с устаревшими базами кода, вы, скорее всего, столкнетесь с @Autowired. Нет немедленной необходимости рефакторить все экземпляры @Autowired, но рассмотрите возможность перехода к внедрению конструктора при обновлении и рефакторинге кода.