🤔 Какие есть проблемы у di?

Dependency Injection (DI) — это паттерн, который упрощает управление зависимостями, но у него есть свои сложности и недостатки.

🟠Усложнение кода и архитектуры
При использовании DI код может стать излишне сложным, особенно если внедрение зависимостей реализуется вручную или через сложные контейнеры.

class Service {
  constructor(repository) {
    this.repository = repository;
  }
}

🟠Производительность (затраты на создание объектов)
Если DI используется через контейнеры, они могут замедлять выполнение программы, так как:
Создание объектов может занимать больше времени (особенно при ленивой инициализации).
Поиск зависимостей в контейнере тоже требует времени.
В Angular, NestJS и других фреймворках DI может потреблять больше ресурсов, чем обычное создание объектов.

🟠Скрытая сложность и магия
Когда зависимости внедряются автоматически через контейнер, код становится менее очевидным.

@Injectable()
class Service {
  constructor(private readonly repository: Repository) {}
}

🟠Проблемы с тестированием
Хотя DI часто называют удобным для тестирования, на практике могут возникнуть сложности:
Если контейнер создаёт объекты динамически, тесты могут работать нестабильно.
Нужно явно мокать зависимости, что может усложнять настройку тестов.

class Service {
  constructor(repository) {
    this.repository = repository;
  }
}

const service = new Service(new Repository()); // Проблема при тестировании – жестко задана зависимость

Здесь тестировать Service сложно, потому что Repository создаётся вручную. Приходится использовать мок-объекты

const mockRepository = { getData: () => "mock data" };
const service = new Service(mockRepository);

🟠DI не всегда нужен
В маленьких проектах использование DI может быть излишним. Простое создание объектов может быть проще и понятнее, чем настройка DI-контейнера.

const repository = new Repository();
const service = new Service(repository);

Ставь 👍 и забирай 📚 Базу знаний