Что такое Dependency Inversion Principle

DIP помогает вам проверить направление зависимостей. Если важная логика напрямую знает про конкретную библиотеку, транспорт, storage или SDK, изменение детали может потянуть изменение этой логики. Это высокая связанность.

Более безопасный подход такой. Сначала вы описываете контракт, который нужен сценарию. Потом подключаете конкретную реализацию. Например, экрану профиля не обязательно знать, что данные приходят через fetch, axios или mock в тесте. Ему важно получить пользователя, обработать загрузку и показать ошибку.

На интервью можно сказать так:

DIP говорит, что бизнес-логика или высокоуровневый UI-сценарий должны зависеть от абстракции, а не от конкретной детали. Деталь, например API-клиент или storage, реализует этот контракт. Так код проще тестировать, менять и расширять.

Вариант с DIP начинается с контракта, который описывает потребность сценария. Контракт не обязан быть классом. В TypeScript часто хватает типа объекта или функции.

type User = {
  id: string;
  name: string;
};

type UserGateway = {
  getCurrentUser(signal?: AbortSignal): Promise<User>;
};

export async function loadProfile(
  gateway: UserGateway,
  signal?: AbortSignal,
) {
  return gateway.getCurrentUser(signal);
}

export const httpUserGateway: UserGateway = {
  async getCurrentUser(signal) {
    const response = await fetch("/api/me", { signal });

    if (!response.ok) {
      throw new Error("Cannot load profile");
    }

    return response.json();
  },
};

Теперь сценарий loadProfile зависит от UserGateway, а не от fetch. Реальная HTTP-деталь живет в адаптере httpUserGateway. В тесте вы можете передать fake-реализацию и не трогать сеть.

Важный нюанс: контракт оставляет AbortSignal. Это не лишняя деталь, а часть безопасного frontend-поведения. Без отмены запроса легко получить race condition или попытку обновить состояние после unmount. Ошибки тоже лучше нормализовать в адаптере или на границе сценария, чтобы компонент мог показать понятный error state, а не падать с необработанным исключением.

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

Если вы видите прямую зависимость от детали, не начинайте с механического создания интерфейса. Сначала найдите границу сценария: что нужно верхнему уровню и какие детали он не должен знать. Потом перенесите конкретную работу в адаптер.

DIP, Dependency Injection и Inversion of Control легко спутать, потому что все три термина связаны с зависимостями.

DIP это принцип. Высокоуровневая логика зависит от контракта, детали реализуют контракт. Dependency Injection это техника. Зависимость приходит снаружи, а не создается внутри. Inversion of Control это более широкая идея. Управление созданием или вызовом передается внешнему механизму.

В React DI может выглядеть очень просто. Вы передаете зависимость через props, параметр hook или Context. DI-контейнер не обязателен.

function ProfilePage({ userGateway }: { userGateway: UserGateway }) {
  // компонент получает зависимость снаружи
  // в тесте сюда можно передать fake gateway
  return <ProfileContent userGateway={userGateway} />;
}

Сам факт передачи через props еще не делает архитектуру хорошей. Если вы передали низкоуровневый AxiosInstance и весь компонент собирает URL сам, зависимость от детали осталась. Лучше передавать контракт уровня сценария.

Отвечайте в три шага. Сначала дайте определение: зависимость идет к абстракции, а не к детали. Затем приведите frontend-пример: API-клиент, storage, analytics SDK или feature flags можно спрятать за контрактом. В конце покажите баланс. Не нужно плодить интерфейсы везде. Абстракция нужна там, где она снижает цену изменений или делает тесты проще.

Короткий ответ можно сформулировать так:

DIP для меня про то, чтобы важная логика не знала конкретные детали инфраструктуры. Например, hook или use case зависит от UserGateway, а конкретная реализация через fetch подключается снаружи. Это упрощает тесты, замену реализации и контроль UI-состояний вроде loading и error. Но я не стал бы делать интерфейс для каждой функции, если нет сменяемости или проблемы с тестированием.