Вопрос проверяет понимание архитектурных недостатков field-injection и умение писать поддерживаемый код.
Field-injection скрывает зависимости класса и делает код менее прозрачным. Такой класс сложно тестировать без Spring-контекста. Нельзя использовать final, что ухудшает надёжность. Также усложняется повторное использование класса вне контейнера. Поэтому field-injection считается плохой практикой.
Несмотря на простоту, field-injection создаёт больше проблем, чем кажется на первый взгляд.
Перед перечислением важно понимать, что удобство написания не равно качеству архитектуры.
Нельзя понять зависимости, посмотрев на конструктор
Класс выглядит проще, чем есть на самом деле
Ухудшается читаемость
Нельзя создать объект через new
Требуется Spring или reflection
Юнит-тесты становятся сложнее
finalЗависимость можно случайно переопределить
Объект может быть изменяемым
Сложнее обеспечить потокобезопасность
Класс нельзя переиспользовать вне контейнера
Нарушается принцип слабой связанности
Быстро писать код
Учебные примеры
Старые проекты
Field-injection ухудшает тестируемость и архитектуру. В продакшн-коде его стоит избегать в пользу constructor-injection.