Что такое Dependency Injection

Dependency Injection отвечает на простой вопрос: кто создает зависимость и кто ее получает. Без DI модуль сам выбирает конкретную реализацию. С DI он получает готовую зависимость снаружи и знает только нужный ему контракт.

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

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

Не сводите ответ к backend-контейнерам. Во frontend DI часто выглядит проще: параметр функции, prop компонента, аргумент хука, фабрика, React Context или Provider на границе приложения.

Начнем с варианта, который лучше не показывать как основной. Хук жестко импортирует конкретный клиент. В демо это может работать, но в продукте быстро появляются проблемы. Тесту приходится мокать модуль или сеть. При быстрой смене userId старый ответ может перетереть новый UI. После размонтирования возможен лишний setState. Ошибка запроса никак не попадет в интерфейс. Если клиент на уровне импорта читает window, localStorage или токен, код сложнее запустить на SSR и в тестах.

// Плохо: зависимость спрятана внутри модуля.
import { apiClient } from "./apiClient";

export function useUser(userId: string) {
  const [user, setUser] = useState<User | null>(null);

  useEffect(() => {
    apiClient.getUser(userId).then(setUser);
  }, [userId]);

  return user;
}

Более безопасный вариант: зависимость передается явно, а сетевой эффект управляется внутри хука. В приложении вы передаете настоящий клиент. В тесте подставляете fake-клиент с тем же контрактом.

type UserApi = {
  getUser: (id: string, options?: { signal?: AbortSignal }) => Promise<User>;
};

type UserState =
  | { status: "loading"; data: null; error: null }
  | { status: "success"; data: User; error: null }
  | { status: "error"; data: null; error: unknown };

export function useUser(userId: string, api: UserApi) {
  const [state, setState] = useState<UserState>({
    status: "loading",
    data: null,
    error: null,
  });

  useEffect(() => {
    const controller = new AbortController();
    let active = true;

    setState({ status: "loading", data: null, error: null });

    api
      .getUser(userId, { signal: controller.signal })
      .then((nextUser) => {
        if (active) {
          setState({ status: "success", data: nextUser, error: null });
        }
      })
      .catch((error) => {
        if (!active || controller.signal.aborted) {
          return;
        }

        setState({ status: "error", data: null, error });
      });

    return () => {
      active = false;
      controller.abort();
    };
  }, [api, userId]);

  return state;
}

Здесь DI помогает не только тестам. Код явно показывает, от чего зависит хук. Cleanup и AbortController уменьшают риск stale UI, лишнего запроса и обновления состояния после размонтирования. Отдельное состояние loading и error помогает не оставлять пользователя с пустым экраном. Следите, чтобы переданный api был стабильным. Например, создавайте его на уровне Provider или через memoization. Иначе эффект будет запускаться чаще, чем нужно.

DI полезен не потому, что делает код "архитектурным". Он полезен, когда снижает конкретный риск: реальный HTTP-запрос в тесте, зависимость от браузерного API на SSR, сложная замена аналитики, скрытый токен или общий кеш.

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

Dependency Injection связан с Dependency Inversion Principle, но это не одно и то же. DIP говорит, что высокоуровневая логика должна зависеть от абстракций, а не от конкретных деталей. DI помогает это сделать: конкретная деталь передается снаружи по ожидаемому контракту.

IoC, или Inversion of Control, шире. Это идея, при которой управление созданием и связями объектов переносится наружу. DI является одним из вариантов IoC.

Service Locator внешне похож на удобный DI, но проблема в другом. Модуль сам идет в глобальный реестр за зависимостью. Сигнатура функции молчит, а внутри может быть запрос к container.get("api"). Для тестов и поддержки это хуже, потому что реальные зависимости приходится искать в реализации.

В React зависимость часто передают через props, но для общих инфраструктурных вещей можно использовать Context. Например, можно положить в Provider API-клиент, logger или feature flags. Компоненты ниже будут получать их через хук.

Это удобно, если зависимость нужна глубоко в дереве. Но Context не стоит превращать в мусорную корзину для любых данных. Если компоненту нужен один callback или один клиент, обычный prop может быть проще и прозрачнее.

Короткий ответ удобно построить в 4 шага:

1. Дайте определение: зависимость передается извне.
2. Назовите пользу: меньше связанность, проще тесты, проще замена реализации.
3. Дайте frontend-пример: API-клиент, storage, analytics, clock, uuid или feature flags.
4. Покажите границу: не надо оборачивать в DI каждую чистую функцию.

Пример ответа:

Dependency Injection это когда модуль не создает зависимости сам, а получает их снаружи. Например, хук может получать API-клиент параметром или через Provider. Тогда в продакшене я передаю реальный клиент, а в тесте fake, и код не зависит от сети или localStorage. Это снижает связанность, но я бы применял DI там, где зависимость реально меняется или имеет внешний эффект, а не для каждой утилиты.

Для frontend-разработчика важно показать не термин, а инженерный смысл. DI помогает держать бизнес-логику отдельно от инфраструктуры: сети, браузерных API, аналитики, времени, id и feature flags.

Если зависимость жестко зашита внутрь модуля, вы платите за это в тестах, SSR, замене реализации и отладке. Если зависимость передана явно, код легче читать: видно, что нужно модулю для работы, и проще подставить безопасную альтернативу.