Внедрение зависимостей в TypeScript

Связанность, которую надо убрать, — это new внутри класса; внедрение через конструктор её выносит. Когда класс конструирует собственных коллабораторов, он зависит от их конкретных типов и деталей конструирования (строки подключения, конфиг ретраев, часы). Он не может работать без них и не может быть переключён на другой. Лекарство — перестать конструировать и начать получать: объяви то, что тебе нужно, как параметр конструктора, типизированный интерфейсом.

// BEFORE — the class reaches out and builds the world
class OrderService {
  private readonly repo = new PostgresOrderRepo(process.env.DB_URL!);
  private readonly mailer = new SmtpMailer(process.env.SMTP!);
  place(order: Order) { /* uses this.repo, this.mailer */ }
}

// AFTER — the class declares what it needs and receives it
interface OrderRepo { save(order: Order): Promise<void>; }
interface Mailer { send(to: string, body: string): Promise<void>; }

class OrderService {
  constructor(
    private readonly repo: OrderRepo,
    private readonly mailer: Mailer,
  ) {}
  place(order: Order) { /* uses this.repo, this.mailer */ }
}

OrderService теперь зависит только от интерфейсов OrderRepo и Mailer. Он понятия не имеет, что Postgres или SMTP существуют. В этом неведении весь смысл: высокоуровневая политика (оформление заказа) больше не знает о низкоуровневом механизме.

Кто-то всё равно должен вызвать new — вытолкни это в корень композиции на краю. Внедрение перемещает конструирование вверх, а не прочь. Конечная остановка — корень композиции: единственное место, максимально близкое к точке входа программы (main, бутстрап HTTP-сервера, старт воркера), где каждый конкретный класс конструируется и связывается воедино. Ядро его никогда не видит.

// main.ts — the composition root: the ONLY place that knows the concretes
function buildApp() {
  const repo = new PostgresOrderRepo(process.env.DB_URL!);
  const mailer = new SmtpMailer(process.env.SMTP!);
  const orders = new OrderService(repo, mailer);   // wire the graph
  return new HttpServer(orders);
}

buildApp().listen(3000);

Теперь стрелка зависимости направлена правильно: детали (PostgresOrderRepo) зависят от абстракций (OrderRepo), определённых рядом с политикой, и только main.ts зависит от деталей. Всё ниже — чистая логика без проводки. Вот что значит «держать ядро в неведении о том, как оно сконструировано» на практике: конструирование — это листовая забота на границе, а не обязанность, размазанная по домену.

Именно это делает ядро тестируемым фейками в юнит-тестах. Поскольку OrderService получает своих коллабораторов, тест может вручить ему тривиальные in-memory-заглушки вместо настоящей базы данных или SMTP-сервера. Ни сети, ни контейнера, ни мокающего фреймворка, переписывающего модули, — просто передай другой объект, удовлетворяющий интерфейсу.

test("place() emails the customer after saving", async () => {
  const saved: Order[] = [];
  const sent: string[] = [];
  const fakeRepo: OrderRepo = { save: async (o) => { saved.push(o); } };
  const fakeMailer: Mailer = { send: async (to) => { sent.push(to); } };

  const service = new OrderService(fakeRepo, fakeMailer);
  await service.place({ id: "1", email: "a@b.com" /* … */ });

  expect(saved).toHaveLength(1);
  expect(sent).toEqual(["a@b.com"]);
});

Фейк занимает несколько строк, потому что шов — это интерфейс, а не конкретный класс, который пришлось бы наследовать или патчить на лету. Если ты ловишь себя на том, что тянешься к тяжёлому мокингу модулей ради теста юнита, — это обычно запах того, что зависимость зашита внутри, а не внедрена. DI превращает «нетестируемо без инфраструктуры» в «тестируемо обычным объектом».

Ручной DI против контейнера — и почему контейнер обычно избыточен на старте. Для небольшого графа корень композиции и есть несколько вызовов new в порядке зависимостей. Это «DI для бедных», и это правда нормально: явно, проверено типами, нулевые зависимости, а стектрейс указывает прямо на проводку. DI-контейнер это автоматизирует — ты один раз регистрируешь OrderRepo → PostgresOrderRepo и просишь контейнер разрешить OrderService, а он конструирует транзитивный граф за тебя.

// manual: explicit, no magic, type-checked by the compiler
const orders = new OrderService(new PostgresOrderRepo(url), new SmtpMailer(smtp));

// container (e.g. tsyringe): a registry resolves the graph for you
container.register<OrderRepo>("OrderRepo", { useClass: PostgresOrderRepo });
const orders = container.resolve(OrderService); // graph built by reflection

Контейнер начинает окупаться, когда граф большой, когда важны времена жизни (синглтоны против per-request-областей) и когда ручная связка тех же десятков сервисов сама становится бременем сопровождения, — то, с чем сталкиваешься в крупном приложении на NestJS или Spring. Ниже этого порога контейнер добавляет зависимость, настройку декораторов/рефлексии и слой косвенности, который затемняет граф, а не проясняет его. Когда НЕ применять: не хватайся за контейнер-фреймворк в маленьком или раннем приложении только потому, что «настоящие приложения используют DI-контейнеры», — ручная проводка в корне композиции уже даёт тебе DIP. Контейнер — это оптимизация под масштаб графа, а не предпосылка для внедрения.