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

Патерни проєктуванняMiddle~2 хв читання

Циклічні залежності - одна з найчастіших і найнебезпечніших проблем при використанні 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	при взаємній необхідності	відклади створення до моменту виклику

Підсумок:

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

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.