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

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

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

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

Контент

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

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

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

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

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

Циклічні залежності - одна з найчастіших і найнебезпечніших проблем при використанні **Dependency Injection (DI)**.
Вона виникає, коли **два (чи більше) компоненти напряму чи опосередковано залежать один від одного**, через що контейнер не може побудувати коректний граф залежностей.

---

### Приклад проблеми

```java
class UserService {
    private final UserRepository repo;
    public UserService(UserRepository repo) { this.repo = repo; }
}

class UserRepository {
    private final UserService service;
    public UserRepository(UserService service) { this.service = service; }
}
```

Контейнер намагається створити `UserService` -> бачить, що потрібен `UserRepository` ->
намагається створити `UserRepository` -> бачить, що потрібен `UserService` -> і зациклюється.

---

## Як уникнути циклічних залежностей

---

### 1. Переглянути архітектуру (основний і правильний спосіб)

Цикл - майже завжди ознака **порушення розділення відповідальності (SRP)**.
Значить, класи роблять більше, ніж повинні.

**Що робити:**

- виділи спільний функціонал у **третій клас**, від якого залежать обидва;
- розділи відповідальність так, щоб зв'язок був **в один бік**.

**Приклад рішення:**

```java
class UserManager {
    private final UserService service;
    private final UserRepository repo;

public UserManager(UserService s, UserRepository r) {
        this.service = s;
        this.repo = r;
    }
}
```

Тепер `UserService` і `UserRepository` більше не залежать один від одного - лише `UserManager` керує ними обома.

---

### 2. Ввести інтерфейс або абстракцію

Часто цикл виникає тому, що класи посилаються **на конкретні реалізації**, а не на **контракти**.

**Що робити:**

- виділи інтерфейс, що описує взаємодію;
- залеж від інтерфейсу, а не від конкретного класу.

**Приклад:**

```java
interface UserNotifier {
    void notifyUser(User user);
}

class UserService {
    private final UserNotifier notifier;
    public UserService(UserNotifier notifier) { this.notifier = notifier; }
}

class EmailNotifier implements UserNotifier { ... }
```

Тепер `UserService` не залежить від конкретної реалізації - контейнер сам підставить потрібну.

---

### 3. Використовувати події або посередників (Event-driven підхід)

Якщо один компонент повинен *реагувати* на дії іншого,
хай вони не залежать напряму, а спілкуються через **події** чи **шину повідомлень**.

**Приклад:**

```java
class UserService {
    private final EventBus bus;
    public void createUser(User u) {
        // ...
        bus.publish(new UserCreatedEvent(u));
    }
}

class NotificationListener {
    @Subscribe
    public void onUserCreated(UserCreatedEvent e) {
        // надіслати сповіщення
    }
}
```

Тепер немає прямої залежності - лише через події.

---

### 4. Впровадження через фабрику (Lazy / Provider)

Якщо залежності дійсно повинні посилатися одна на одну (рідкісний, але можливий випадок),
можна використовувати **відкладене впровадження (lazy injection)** чи **фабрики**, щоб не створювати об'єкти одразу.

**Як це виглядає:**

```java
class A {
    private final Provider<B> bProvider;
    public A(Provider<B> bProvider) { this.bProvider = bProvider; }

public void doSomething() {
        B b = bProvider.get(); // створюється при першому виклику
    }
}
```

Це розриває цикл на момент ініціалізації, тому що `B` створюється **пізніше**.

---

### 5. Використовувати композицію замість залежності

Іноді клас не повинен "знати" інший клас, а просто **володіти екземпляром і делегувати** частину логіки.

**Приклад:**

```java
class UserController {
    private final UserService service = new UserService(new UserRepository());
}
```

Контейнер не потрібен, якщо об'єкт можна створити локально, особливо для простих допоміжних залежностей.

---

## Висновок

> Циклічні залежності - сигнал не до "обходу помилки", а до **архітектурного перегляду**.

| Метод | Коли застосовувати | Суть |
|---|---|---|
| Рефакторинг архітектури | завжди | розділи класи за відповідальністю |
| Введення інтерфейсів | при сильній зв'язаності | залеж від контрактів, не реалізацій |
| Події / посередники | при асинхронній взаємодії | обмін даними без прямих посилань |
| Lazy / Provider | при взаємній необхідності | відклади створення до моменту виклику |

---

**Підсумок:**

> Щоб уникнути циклічних залежностей, будуй систему так, щоб зв'язки були **спрямовані, а не взаємні**.
> Якщо два компоненти "потрібні один одному", значить, у коді є **третя сутність**, яка повинна керувати ними обома.

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

Для рев’юера

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

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