---

🟢 Junior Level

Просте визначення

DIP (Dependency Inversion Principle) — це правило, що каже: «Залеж від абстракцій, а не від конкретних реалізацій». DI (Dependency Injection) — це спосіб, яким ми передаємо ці абстракції в об’єкт ззовні, замість того щоб створювати їх всередині. DIP — це «що ми хочемо», DI — це «як ми це робимо».

Аналогія

Уявіть розетку в стіні. Вам не важливо, звідки приходить електрика — з АЕС, вітряка чи сонячної панелі. Вам потрібен тільки стандартний інтерфейс (вилка/розетка). DIP — це стандарт розетки. DI — це те, що електрик приходить і підключає потрібне джерело до цієї розетки за вас.

Простий приклад

// ПОГАНО: порушуємо DIP — сервіс знає про конкретну БД
public class OrderService {
    private MySqlRepository repo = new MySqlRepository();
}

// ДОБРЕ: залежимо від абстракції, реалізація приходить ззовні (DI)
public class OrderService {
    private final OrderRepository repo;

    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }
}

Коли використовувати

• Коли хочете легко підміняти реалізації (наприклад, PostgreSQL на MongoDB).
• Коли потрібно писати юніт-тести з моками замість реальної БД.
• Коли працюєте в команді і хочете розділити інтерфейси і реалізації.

---

🟡 Middle Level

Як це працює всередині

Зв’язка DIP + DI працює через три концепції:

Концепція	Роль	Приклад
DIP	Архітектурний принцип: високорівнева логіка не повинна залежати від деталей	OrderService залежить від OrderRepository, а не від MySqlRepository
DI	Технічний прийом: передача залежності ззовні	Передаємо OrderRepository через конструктор
IoC	Фреймворк керує життєвим циклом об’єктів	Spring сам створює біни і зв’язує їх

IoC слідує Hollywood Principle: «Don’t call us, we’ll call you» — контейнер сам вирішує, коли створити об’єкт і викликати його методи.

Практичне застосування

Constructor Injection (рекомендований підхід):

public class OrderService {
    private final OrderRepository repo;

    public OrderService(OrderRepository repo) {
        this.repo = Objects.requireNonNull(repo); // fail-fast
    }
}

Setter Injection (для опціональних залежностей):

public void setCacheProvider(CacheProvider cache) {
    this.cache = cache;
}

DI vs Service Locator

Підхід	Плюси	Мінуси
DI	Залежності видні в конструкторі, легко мокати, fail-fast при старті	Більше boilerplate при ручному використанні
Service Locator	Менше коду в конструкторі	Приховані залежності, складно тестувати (потрібно мокати статичний контекст), залежності невідомі до рантайму

// Service Locator — погано
OrderRepository repo = ServiceContext.get("repo"); // Прихована залежність

// DI — добре
public OrderService(OrderRepository repo) { ... }   // Явна залежність

Коли НЕ використовувати

• Прості скрипти і утиліти — overhead від інтерфейсів не окупається.
• Класи без залежностей — якщо клас не залежить від зовнішніх сервісів, DI не потрібен.
• Чисто функціональний код — функції без стану не потребують впровадження.

---

🔴 Senior Level

Глибока внутрішня реалізація

Реалізація DI в сучасних JVM

Reflection-based (Spring, Guice):

• Контейнер сканує анотації через Class.getDeclaredFields().
• Викликає Constructor.newInstance() або Field.set() через рефлексію.
• Вартість: перший запуск повільний — на граф з 1000 бінів Spring витрачає 0.5–3 сек на старті тільки на рефлексію і вирішення залежностей.

Source Generation (Dagger 2, Micronaut):

• Генерує код на етапі компіляції (*_Factory.java класи).
• В рантаймі — звичайний new виклик без рефлексії.
• Вартість: оверхед ~0 мс на старті, граф з 1000 бінів ініціалізується за 10–50 мс.

Bytecode-рівень

Constructor Injection дозволяє позначити поля як final:

private final OrderRepository repo;

На рівні bytecode це дає:

• Поле отримує модифікатор ACC_FINAL — JVM може inline-ити посилання.
• JIT-компілятор використовує цю гарантію для devirtualization — якщо тип фінального поля відомий, виклики методів можуть бути зайлайненими без віртуальної диспетчеризації.
• Без final JIT повинен вставляти safepoint-перевірки на випадок повторної ініціалізації.

Архітектурні trade-offs

Підхід	Pros	Cons
Constructor DI	Fail-fast (NPE на старті), поля final, іммутабельність, легко тестувати	Конструктор може мати 10+ параметрів — запах «занадто багато обов’язків»
Setter DI	Опціональні залежності, можна міняти на льоту	Залежності можуть бути null до ініціалізації, складніше відстежити порядок
Field DI (через рефлексію)	Мінімум boilerplate	Не можна зробити поля final, приховані залежності, неможливо без контейнера
Pure DI (ручний)	Повний контроль, нульовий overhead, прозорість	Ручне управління графом, boilerplate росте з розміром проекту

Edge Cases

1. Circular Dependencies:

class A { A(B b) { ... } }
class B { B(A a) { ... } }

Spring вирішує constructor circular dependencies викиданням BeanCurrentlyInCreationException. Setter-based DI дозволяє цикли через проксі, але це маскує проблему дизайну. Цикл — індикатор того, що DIP перетворився на спагеті.

Рішення: введіть третій клас-координатор, використовуйте @Lazy (костиль), або перепроектуйте межі відповідальності.

2. Optional Dependencies:

public OrderService(Optional<CacheProvider> cache, @Nullable MetricsCollector metrics) { ... }

Використовуйте Optional<T> або @Nullable — але не зловживайте: якщо залежність опціональна в 90% випадків, можливо, це не залежність, а декоратор.

3. Conditional Dependencies:

@Bean
@ConditionalOnProperty("cache.enabled")
public CacheProvider cache() { ... }

Spring підтримує умовні біни, але це ускладнює аналіз графа — ви не можете статично визначити, які залежності будуть доступні.

Performance Implications

Метрика	Reflection-based (Spring)	Compile-time (Dagger)
Startup (100 бінів)	100–300 мс	5–15 мс
Startup (1000 бінів)	1–3 сек	30–80 мс
Memory per bean	~200 байт (reflective metadata)	~0 байт
Runtime invocation	0 мс (кешується після старту)	0 мс
GraalVM native	Потребує reflection-config	Працює «з коробки»

Constructor Injection + final fields: JVM може inline-ити фінальні поля після escape analysis. В hotspot-профілюванні це дає 2–5% прискорення на методах з частим доступом до полів.

Memory Implications і GC Impact

• Кожен бін в Spring-контейнері займає пам’ять: сам об’єкт + проксі (CGLIB — бібліотека для генерації підкласів-проксі на рівні bytecode / JDK Dynamic Proxy ~1–2 КБ на проксі) + метадані в BeanDefinition.
• В додатках з 5000+ бінами це додає 5–15 МБ heap тільки на інфраструктуру.
• Singleton scope: один об’єкт на весь JVM — мінімальний GC impact.
• Prototype scope: новий об’єкт при кожному запиті — підвищене навантаження на Young GC, особливо якщо об’єкти “живуть” довго і мігрують в Old Generation.

Thread Safety

• Singleton біни повинні бути thread-safe — Spring не синхронізує доступ до бінам.
• Constructor Injection гарантує safe publication — фінальні поля видні всім потокам після завершення конструктора (happens-before по JLS §17.5).
• Field Injection через рефлексію не дає safe publication гарантій — в теорії потік може побачити частково ініціалізоване поле.

Production War Story

Проблема: Мікросервіс обробки замовлень мав 2000+ Spring-бінів. Startup займав 45 секунд. При деплої в Kubernetes liveness probe вбивав поди до їх повного старту, створюючи cascade restart.

Діагностика: spring-boot-starter-actuator + /actuator/startup показав, що 30 секунд витрачається на reflection scanning і proxy creation для бінів, які потрібні тільки в 3 з 20 endpoint’ів.

Рішення:

1. Міграція на Micronaut (compile-time DI) — startup впав до 2 секунд.
2. Розділення моноліту на 4 модуля з lazy loading — кожен модуль завантажував тільки свої біни.
3. Заміна @Autowired на Constructor Injection — дозволило виявити 12 невикористаних залежностей.

Monitoring і Diagnostics

ArchUnit — перевіряє архітектурні правила на рівні тестів:

@ArchTest
static final ArchRule no_controller_should_access_repository_directly =
    noClasses().that().resideInAPackage("..controller..")
        .should().dependOnClassesThat().resideInAPackage("..repository..");

SonarQube — правило S3010 detects DI violations (fields injected without constructor).

Spring Boot Actuator — /actuator/beans показує весь граф залежностей.

jdeps (JDK tool) — аналізує залежності на рівні bytecode.

Best Practices для Highload

1. Constructor Injection як переважний підхід — fail-fast, final fields, JIT-friendly. Але для опціональних залежностей допустимий Setter Injection.
2. Compile-time DI для serverless/lambda — холодний старт критичний.
3. Мінімізуйте граф — чим менше бінів, тим швидший старт і менше heap.
4. Уникайте @Autowired на полях — приховані залежності + no safe publication.
5. Використовуйте Pure DI для маленьких модулів — без фреймворку, просто передавайте залежності вручну.

Резюме для Senior

• DI — це «руки» для реалізації архітектурної ідеї DIP.
• Constructor Injection — золотий стандарт: fail-fast, final fields, JIT-оптимізації.
• DIP/DI — це не про «інтерфейс ради інтерфейсу», а про управління зв’язаністю.
• Reflection-based DI зручний, але compile-time DI перемагає в performance-sensitive сценаріях.
• Не плутайте DI з фреймворками. DI можна робити вручну («Pure DI»).

---

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

Обов’язково знати:

• DIP — “що” (залежати від абстракцій), DI — “як” (передача через конструктор/поле/setter)
• Constructor Injection — золотий стандарт: fail-fast, final поля, JIT-оптимізації, safe publication
• Reflection-based DI (Spring): 0.5-3 сек на 1000 бінів; Compile-time (Dagger): 10-50 мс
• final поля → ACC_FINAL → JIT devirtualization → inlining без safepoint-перевірок
• Circular Dependencies → BeanCurrentlyInCreationException; рішення: координатор, @Lazy, перепроектування
• Singleton біни повинні бути thread-safe; Constructor Injection гарантує safe publication (happens-before)

Часті уточнюючі запитання:

• Constructor vs Setter vs Field Injection? — Constructor: fail-fast, final, тестованість; Setter: опціональні; Field: приховані залежності, немає safe publication
• DI vs Service Locator? — DI: залежності видні в конструкторі, легко мокати; Service Locator: приховані залежності, складно тестувати
• Чому Spring повільніший за Dagger? — Рефлексія при старті vs генерація коду на компіляції
• Що таке Pure DI? — Ручне створення і передача залежностей без фреймворку

Червоні прапори (НЕ говорити):

• “Field Injection через @Autowired — це зручно” (приховані залежності, не можна зробити final, no safe publication)
• “Circular Dependency — Spring розрулить” (маскування проблеми дизайну через проксі)
• “Кожен клас повинен мати інтерфейс для DI” (Abstractions Overkill, порушення YAGNI)

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

• [[8. Що таке принцип Dependency Inversion]]
• [[15. Як SOLID допомагає в тестуванні коду]]
• [[20. Чи можна слідувати всім принципам SOLID одночасно]]
• [[22. Які антипатерни суперечать принципам SOLID]]