🍃 Розділ 5 · Питання #3

Який тип ін'єкції рекомендується і чому

Офіційна документація Spring Framework однозначно рекомендує використовувати Constructor Injection (впровадження через конструктор) для всіх обов'язкових залежностей додатку.

🍃 Spring Spring Boot 📄 Вихідний Markdown

🟢 Junior Level

1. Офіційна рекомендація

Офіційна документація Spring Framework однозначно рекомендує використовувати Constructor Injection (впровадження через конструктор) для всіх обов’язкових залежностей додатку.

// ✅ ЗОЛОТИЙ СТАНДАРТ СУЧАСНОЇ РОЗРОБКИ:
@Service
@RequiredArgsConstructor
public class OrderService {
    private final OrderRepository orderRepository;
    private final PaymentGateway paymentGateway;

    // Конструктор генерується Lombok або пишеться вручну
}

2. Ключові причини вибору Constructor Injection

  1. Гарантія незмінності (final): залежності неможливо підмінити або випадково перезаписати після створення екземпляра біна.
  2. Захист від NullPointerException: об’єкт неможливо сконструювати в неповному або напівготовому стані — компілятор і IoC-контейнер вимагають передачі всіх аргументів.
  3. Легке та чисте Unit-тестування: для тестування класу не потрібні контекст Spring, рефлексія Mockito або запуск повільного контейнера: 
    @Test
void shouldProcessOrder() {
    OrderRepository mockRepo = mock(OrderRepository.class);
    PaymentGateway mockGateway = mock(PaymentGateway.class);
       
    // Чистий Java-код без анотацій Spring:
    OrderService service = new OrderService(mockRepo, mockGateway);
    service.process(new Order());
}
  4. Принцип Fail-Fast: якщо потрібний бін відсутній у контексті або допущено помилку в конфігурації, додаток аварійно зупиниться з чіткою помилкою в момент старту, а не під час виконання реального клієнтського запиту в продакшені.

🟡 Middle Level

1. Архітектурний детектор порушення SRP

Однією з найважливіших прихованих переваг Constructor Injection є те, що він слугує природним індикатором чистоти архітектури (Code Smell Detector):

// ❌ АНТИПАТЕРН: Field Injection маскує надмірне розростання класу
@Service
public class MegaService {
    @Autowired private Repo1 r1;
    @Autowired private Repo2 r2;
    @Autowired private Repo3 r3;
    @Autowired private Service1 s1;
    @Autowired private Service2 s2;
    @Autowired private Service3 s3;
    @Autowired private MailSender mail;
    @Autowired private SmsSender sms;
    @Autowired private MetricsClient metrics;
    // Візуально здається компактним, але клас виконує ЗАБАГАТО функцій!
}

Якщо переписати цей клас на ін’єкцію через конструктор:

public MegaService(Repo1 r1, Repo2 r2, Repo3 r3, Service1 s1, 
                   Service2 s2, Service3 s3, MailSender mail, 
                   SmsSender sms, MetricsClient metrics) { ... }

Конструктор із 9 аргументами миттєво сигналізує про грубе порушення Single Responsibility Principle (SRP). Розробник одразу бачить необхідність декомпозиції класу на кілька незалежних сфокусованих сервісів.

2. Коли виправданий Setter Injection?

Впровадження через сетери не заборонене, проте має чітко обмежену нішу:

  • Опціональні залежності (Optional Dependencies): сервіс може повноцінно функціонувати навіть за відсутності залежності, використовуючи дефолтну поведінку (@Autowired(required = false)).
  • Зв’язування конфігурації Spring Boot: механізм @ConfigurationProperties використовує стандартні сетери для відображення властивостей з файлу application.yaml у поля Java-біна.

🔴 Senior Level

1. Правила вирішення конструкторів у ядрі Spring

Під час інстанціювання біна контейнер Spring застосовує суворий алгоритм вибору конструктора:

  1. Один конструктор у класі:
    Починаючи зі Spring 4.3, анотація @Autowired над єдиним конструктором не потрібна. Spring автоматично обирає його для DI.
  2. Кілька конструкторів:
    • Spring шукає конструктор, явно позначений анотацією @Autowired.
    • Якщо анотованого конструктора немає, Spring намагається використати дефолтний конструктор без аргументів (no-arg constructor). Залежності в такому разі можуть бути впроваджені лише через сетери або поля.
    • Якщо конструктора без параметрів немає і жоден конструктор не позначений @Autowired, контейнер аварійно зупиняє запуск з винятком BeanCreationException.

2. Специфіка CGLIB-проксіювання та логіка в конструкторі

Коли бін позначається анотаціями @Transactional, @Async, @Cacheable або @Secured, Spring створює динамічний CGLIB-підклас (проксі):

       [ UserService$$SpringCGLIB$$0 ]  (Проксі-підклас)
                      │ extends
                      ▼
               [ UserService ]          (Цільовий клас)

Критичне правило проєктування: Конструктор біна повинен виконувати виключно збереження аргументів у поля:

public UserService(UserRepository repo) {
    this.repo = repo; // Єдина допустима дія!
}

[!CAUTION] Ніколи не виконуйте важку бізнес-логіку, звернення до БД або мережеві виклики всередині конструктора!

  1. На момент виконання конструктора AOP-проксі ще не створено: анотації @Transactional та @Async всередині конструктора не діють.
  2. При генерації CGLIB-проксі конструктор суперкласу може викликатися двічі (залежно від версії та механізму байткод-генерації).
  3. Будь-яка логіка пост-ініціалізації має бути винесена в метод з анотацією @PostConstruct або реалізацію InitializingBean.

3. Циклічні залежності та ціна застосування @Lazy

Constructor Injection унеможливлює створення циклічних залежностей, що змушує команду підтримувати правильну модульну архітектуру:

// Бін A вимагає B, Бін B вимагає A:
@Service
public class ServiceA {
    public ServiceA(@Lazy ServiceB serviceB) { ... }
}

Хоча анотація @Lazy знімає блокування (Spring впроваджує динамічний CGLIB-проксі-заглушку замість реального екземпляра $B$, відкладаючи фактичне створення до першого виклику методу), у production-коді це вважається технічним боргом та архітектурною латкою.

Правильне рішення: архітектурна декомпозиція з виділенням спільного сервісу $C$, від якого односпрямовано залежатимуть $A$ і $B$, або перехід на асинхронні події через ApplicationEventPublisher.

🎯 Шпаргалка для інтерв’ю

30-секундна відповідь (Elevator Pitch)

«Офіційний та індустріальний стандарт у Java — Constructor Injection. Він забезпечує:

  1. Незмінність залежностей (final-поля) та безпечну публікацію в пам’яті за специфікацією JMM.
  2. Надійний захист від NullPointerException завдяки гарантії повної ініціалізації об’єкта під час конструювання.
  3. Просте написання швидких та ізольованих Unit-тестів без завантаження Spring-контексту (new MyService(mockRepo)).
  4. Раннє виявлення помилок конфігурації та циклічних залежностей під час старту додатку (Fail-Fast).
  5. Слугує візуальним детектором порушення Single Responsibility Principle при збільшенні кількості аргументів».

3 каверзних запитання з інтерв’ю та відповіді

1. Чому у Spring 4.3+ прибрали обов’язкову вимогу ставити @Autowired над конструктором?

Відповідь: Це частина еволюції Spring до концепції неінвазивного фреймворку (Non-Invasive Framework). Якщо в класі оголошено єдиний конструктор з параметрами, намір розробника цілком однозначний: об’єкт не може існувати без цих залежностей. Усунення обов’язкової анотації @Autowired дозволяє проєктувати чисті Java POJO-класи, які взагалі не містять імпортів із пакетів org.springframework.*.

2. Чому Field Injection вважається антипатерном, якщо він настільки часто зустрічається в навчальних статтях?

Відповідь: У статтях Field Injection використовується виключно заради економії вертикального місця в кодових блоках. У продакшені Field Injection створює критичні проблеми: неможливо зробити поля final, залежності приховані з публічного контракту класу (конструктор без аргументів здається робочим), неможливо написати ізольований unit-тест без рефлексії Mockito/Spring, а циклічні залежності маскуються аж до появи раптових NullPointerException у рантаймі.

3. Що станеться, якщо у класу є два конструктори і над жодним не стоїть @Autowired?

Відповідь: Spring спробує знайти дефолтний конструктор без параметрів (no-arg constructor). Якщо він присутній, Spring використає його, а залежності спробує впровадити через сетери чи поля. Якщо ж обидва конструктори приймають аргументи і жоден не має анотації @Autowired, Spring не зможе зробити вибір самостійно й аварійно завершить роботу з винятком BeanCreationException.

Типові помилки та Red Flags

  • ❌ Твердження, що Field Injection є прийнятним у Production: Свідчить про нерозуміння принципів тестування та ООП.
  • ❌ Важка ініціалізація (I/O, SQL-запити) в конструкторі: Уся логіка має бути у @PostConstruct, оскільки на етапі конструктора AOP-проксі ще не ініціалізовано.
  • ❌ Використання @Lazy як постійного системного рішення для циклів: Маскує дефекти архітектури сервісів.
  • ❌ Використання Setter Injection для обов’язкових залежностей: Створює ризик отримати недоініціалізований об’єкт із null-полями.

Пов’язані теми