Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «Чим DI відрізняється від звичайного впровадження залежностей вручну?». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (UA)

Різниця між **Dependency Injection (DI)** і **ручним впровадженням залежностей** - у тому, ***хто керує процесом створення і зв'язування об'єктів***.

Обидва підходи *впроваджують* залежності, але роблять це по-різному:

---

### 1. Ручне впровадження залежностей: контроль у програміста

Ти сам створюєш об'єкти і передаєш їх в інші класи.

```java
Database db = new MySQLDatabase();
UserService userService = new UserService(db);
```

**Плюси:**

- Просто, прозоро, без додаткової магії.
- Підходить для маленьких систем.

**Мінуси:**

- Програміст вручну керує залежностями та їх життєвим циклом.
- При зростанні проекту код ініціалізації перетворюється на "драбину конструкторів":

```javascript
  A залежить від B, B залежить від C, C залежить від D...
  ```
- Заміна реалізації вимагає переписування точок створення.
- Важко масштабувати і тестувати - все жорстко зв'язано.

---

### 2. Dependency Injection (через контейнер IoC): контроль у фреймворка

DI-контейнер (наприклад, **Spring**, **Guice**, **.NET Core**) сам:

- створює потрібні об'єкти,
- розв'язує залежності,
- керує їх життєвим циклом (singleton, prototype і т. д.),
- і "вприскує" їх туди, де вони потрібні.

```java
@Component
class UserService {
    private final Database db;
    public UserService(Database db) { this.db = db; }
}
```

Контейнер сам знайде потрібну реалізацію `Database` і підставить її в `UserService`.

**Плюси:**

- Архітектура стає **гнучкою і модульною**.
- **Легко підміняти реалізації** - без переписування коду.
- **Управління життєвим циклом** - контейнер сам вирішує, коли створювати і знищувати об'єкти.
- **Спрощене тестування** - можна підставити mock через конфігурацію.

**Мінуси:**

- Потребує вивчення контейнера.
- Складніше налагоджувати "приховану магію", якщо не знаєш, як працює фреймворк.

---

### Підсумкове порівняння

| Критерій | Ручне впровадження | Dependency Injection |
|---|---|---|
| Хто створює залежності | Програміст | Контейнер (фреймворк) |
| Масштабованість | Низька | Висока |
| Гнучкість | Обмежена | Велика |
| Управління життєвим циклом | Вручну | Автоматично |
| Тестування | Складніше | Простіше |
| Застосування | Малі проекти | Середні та великі системи |

---

**Висновок:**

> Ручне впровадження - це просто "передача об'єктів руками".
> Dependency Injection - це **автоматизована система управління залежностями**, де ти описуєш *що потрібно*, а контейнер сам вирішує *як і коли це створити*.

Хочеш - покажу короткий приклад на коді, де видно, як один і той самий проект виглядає **до** і **після DI** (на Java чи Python)?

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати369 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.