Что обычно внедряют через DI?

Что внедряют через Dependency Injection (DI)

Dependency Injection (DI, внедрение зависимостей) — это паттерн проектирования, при котором зависимости объекта предоставляются ему извне, а не создаются внутри него. Это позволяет достичь слабой связанности (loose coupling), улучшить тестируемость и упростить поддержку кода.

Типы зависимостей, которые обычно внедряются

1. Сервисы приложения

• Сервисы данных (API-клиенты, репозитории):

  // Без DI
  class UserService {
    private apiClient = new ApiClient();
  
    getUsers() {
      return this.apiClient.fetch('/users');
    }
  }
  
  // С DI
  class UserService {
    constructor(private apiClient: ApiClient) {}
  
    getUsers() {
      return this.apiClient.fetch('/users');
    }
  }
  

• Бизнес-логика (обработчики заказов, расчётные модули).
• Сервисы утилит (валидаторы, форматтеры, хелперы).

2. Внешние зависимости и интеграции

• HTTP-клиенты (Axios, Fetch, специализированные SDK).
• Сервисы сторонних API (платёжные системы, геолокация, аналитика).
• Базы данных и ORM (клиенты PostgreSQL, MongoDB, Prisma, TypeORM).
• Кеширование (Redis, Memcached клиенты).

3. Конфигурация и настройки

• Объекты конфигурации (параметры подключения, настройки окружения).

  class DatabaseService {
    constructor(private config: DatabaseConfig) {
      // config содержит host, port, credentials
    }
  }
  

• Константы и feature flags.

4. Состояние приложения (State Management)

• Менеджеры состояния (MobX stores, Redux slices, контексты React).
• Клиенты состояния (Apollo Client для GraphQL, React Query).

5. Утилиты и инфраструктурные сервисы

• Логирование (логгеры с разными уровнями и назначениями).
• Мониторинг и телеметрия (Sentry, Application Insights клиенты).
• Аутентификация и авторизация (сервисы токенов, провайдеры OAuth).
• Локализация (i18n-сервисы, словари переводов).

6. Абстракции и интерфейсы

• Порты (Ports) в архитектуре Hexagonal:

  // Интерфейс (порт)
  interface PaymentGateway {
    processPayment(amount: number): Promise<PaymentResult>;
  }
  
  // Внедряемая реализация (адаптер)
  class StripePaymentGateway implements PaymentGateway {
    async processPayment(amount: number) {
      // Реализация для Stripe
    }
  }
  
  class OrderService {
    constructor(private paymentGateway: PaymentGateway) {}
  }
  

• Абстрактные классы и их реализации.

Почему именно эти зависимости?

• Тестируемость: Легко подменить реальные сервисы моками или стабами.

  // В тесте используем mock вместо реального API
  const mockApiClient = { fetch: jest.fn() };
  const service = new UserService(mockApiClient);
  

• Гибкость: Можно менять реализации без изменения потребителей (например, перейти с REST на GraphQL).
• Управление жизненным циклом: DI-контейнеры контролируют создание экземпляров (синглтоны, transient, scoped).
• Соблюдение DIP (Dependency Inversion Principle): Модули высокого уровня не зависят от модулей низкого уровня, оба зависят от абстракций.

Пример в современном фронтенде (Angular)

// Сервис, внедряемый в компонент
@Injectable({ providedIn: 'root' })
export class AuthService {
  constructor(
    private http: HttpClient,          // Внешняя зависимость
    private config: AppConfig,         // Конфигурация
    private logger: LoggerService      // Утилита
  ) {}
}

@Component({
  selector: 'app-login',
  template: `...`
})
export class LoginComponent {
  constructor(private authService: AuthService) {}  // DI через конструктор
}

В React с использованием Context API или библиотек (InversifyJS, TSyringe) паттерн применяется аналогично, хотя и менее явно.

Ключевые выводы

1. Внедряется всё, что может меняться или требует изоляции — сервисы, интеграции, конфигурация.
2. Не внедряются примитивные значения (строки, числа), статические утилиты (Math, Date) и внутренние вспомогательные классы, не имеющие внешних зависимостей.
3. Основная цель — сделать код предсказуемым, тестируемым и готовым к изменениям, что критично для сложных frontend-приложений с постоянно развивающейся бизнес-логикой.

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