От чего внедрение зависимостей оберегает на практике?

Внедрение зависимостей (Dependency Injection): практическая ценность

DI (Dependency Injection) — это не просто паттерн проектирования, это **спасение от целого класса проблем**.

Проблема БЕЗ DI

Плотная связанность (Tight Coupling):

// Плохо: сервис создаёт свои зависимости
class UserService {
  private db: Database;
  private cache: Redis;
  private emailService: EmailService;
  
  constructor() {
    // Сервис СОЗДАЁТ свои зависимости
    this.db = new Database('prod-database');
    this.cache = new Redis('prod-redis');
    this.emailService = new EmailService('prod-smtp');
  }
  
  async register(email: string, password: string) {
    const user = await this.db.create({ email, password });
    await this.cache.set(`user:${user.id}`, user);
    await this.emailService.send(email, 'Welcome!');
    return user;
  }
}

// Использование
const userService = new UserService();
await userService.register('john@example.com', 'pass123');

Проблемы:

1. Невозможно тестировать (БД реальная!)

describe('UserService.register', () => {
  it('should create user', async () => {
    // Но сервис подключится к РЕАЛЬНОЙ БД production!
    const service = new UserService();
    await service.register('test@example.com', 'pass');
    // Тест создаёт реальных пользователей? НЕТ!
  });
});

1. Невозможно переиспользовать в разных контекстах

// Хотим для тестирования использовать mock БД
// Но это невозможно — БД жёстко закодирована!

// Хотим для разработки использовать local БД
// Но это невозможно — она всегда production!

1. Трудно масштабировать

// Завтра нужно добавить:
// - Логирование
// - Rate limiting
// - Analytics
// - Cache invalidation

// Но всё это нужно менять в конструкторе
// И это может сломать существующий код

Решение: Dependency Injection

Правильно: зависимости внедряются снаружи

// Сервис получает зависимости как параметры
class UserService {
  constructor(
    private db: Database,
    private cache: Redis,
    private emailService: EmailService
  ) {}
  
  async register(email: string, password: string) {
    const user = await this.db.create({ email, password });
    await this.cache.set(`user:${user.id}`, user);
    await this.emailService.send(email, 'Welcome!');
    return user;
  }
}

// Production
const dbProd = new Database('prod-database');
const cacheProd = new Redis('prod-redis');
const emailProd = new EmailService('prod-smtp');
const userService = new UserService(dbProd, cacheProd, emailProd);

// Test
const dbMock = new MockDatabase();
const cacheMock = new MockRedis();
const emailMock = new MockEmailService();
const testService = new UserService(dbMock, cacheMock, emailMock);

От чего DI оберегает

1. Невозможность тестирования

С DI — легко тестировать:

describe('UserService.register', () => {
  let service: UserService;
  let dbMock: MockDatabase;
  let cacheMock: MockRedis;
  let emailMock: MockEmailService;
  
  beforeEach(() => {
    dbMock = new MockDatabase();
    cacheMock = new MockRedis();
    emailMock = new MockEmailService();
    service = new UserService(dbMock, cacheMock, emailMock);
  });
  
  it('should create user and cache it', async () => {
    const user = await service.register('john@example.com', 'pass');
    
    // Проверяем что БД был вызван
    expect(dbMock.create).toHaveBeenCalledWith({
      email: 'john@example.com',
      password: 'pass'
    });
    
    // Проверяем что кэш был обновлён
    expect(cacheMock.set).toHaveBeenCalledWith(
      `user:${user.id}`,
      user
    );
    
    // Проверяем что email был отправлен
    expect(emailMock.send).toHaveBeenCalledWith(
      'john@example.com',
      'Welcome!'
    );
  });
  
  it('should handle database error', async () => {
    // Мокируем ошибку
    dbMock.create = jest.fn().mockRejectedValue(new Error('DB Error'));
    
    // Проверяем что сервис правильно обрабатывает
    await expect(
      service.register('john@example.com', 'pass')
    ).rejects.toThrow('DB Error');
  });
});

Результат: 100% покрытие тестами, нет обращений к real БД!

2. Плотная связанность

БЕЗ DI:

class EmailService {
  constructor() {
    this.smtp = new SMTPClient('prod-smtp');
  }
}

class UserService {
  constructor() {
    this.email = new EmailService();  // Жёсткая связь
  }
}

// Хотим использовать TwilioEmail вместо SMTP?
// Нужно менять UserService!
// Это нарушает принцип Open/Closed

С DI:

interface IEmailService {
  send(email: string, subject: string, body: string): Promise<void>;
}

class SMTPEmailService implements IEmailService {
  async send(email, subject, body) { /* ... */ }
}

class TwilioEmailService implements IEmailService {
  async send(email, subject, body) { /* ... */ }
}

class UserService {
  constructor(private emailService: IEmailService) {}
  // Не важно какая реализация, интерфейс одинаков!
}

// Production: SMTP
const emailService = new SMTPEmailService();
const userService = new UserService(emailService);

// Staging: Twilio
const emailService = new TwilioEmailService();
const userService = new UserService(emailService);

Результат: одна строка кода меняет реализацию!

3. Трудность расширения

БЕЗ DI:

class UserService {
  constructor() {
    this.db = new Database();
    this.cache = new Redis();
    this.email = new EmailService();
    // Завтра нужен логирование? Пишем в constructor
    // Нужна аналитика? Пишем в constructor
    // Нужен rate limiting? Пишем в constructor
    // Constructor становится всё больше! 50+ строк
  }
}

// Каждый новый класс который требует UserService
// получает все эти зависимости (хочет или нет)

С DI:

class UserService {
  constructor(
    private db: Database,
    private cache: Redis,
    private email: IEmailService,
    private logger?: ILogger,        // Optional
    private analytics?: IAnalytics,   // Optional
    private rateLimiter?: IRateLimiter // Optional
  ) {}
}

// Используем только нужные зависимости
const service1 = new UserService(db, cache, email);
// Или с полным набором
const service2 = new UserService(
  db,
  cache,
  email,
  logger,
  analytics,
  rateLimiter
);

4. Сложность конфигурирования

БЕЗ DI:

class AuthService {
  constructor() {
    this.db = new Database(process.env.DB_URL);  // Жёстко зависит от env!
  }
}

// Тест:
process.env.DB_URL = 'test-database';
const service = new AuthService();
// Но что если другой тест установил другой DB_URL?
// Race condition!

С DI:

const db = new Database(process.env.DB_URL);
const service = new AuthService(db);

// Тест:
const dbTest = new Database('test-database');
const testService = new AuthService(dbTest);
// Каждый тест контролирует свои зависимости

5. Невозможность мокирования внешних сервисов

БЕЗ DI:

class PaymentService {
  async pay(amount: number) {
    const stripe = new Stripe(process.env.STRIPE_KEY);
    return await stripe.charge(amount);
    // Как тестировать БЕЗ реальных charges?
    // Невозможно! Реальные деньги в тестах!
  }
}

С DI:

interface IPaymentGateway {
  charge(amount: number): Promise<{ transactionId: string }>;
}

class StripePaymentGateway implements IPaymentGateway {
  constructor(private stripe: Stripe) {}
  async charge(amount: number) { /* ... */ }
}

class MockPaymentGateway implements IPaymentGateway {
  async charge(amount: number) {
    return { transactionId: 'mock-123' };  // Fake
  }
}

class PaymentService {
  constructor(private gateway: IPaymentGateway) {}
  async pay(amount: number) {
    return await this.gateway.charge(amount);
  }
}

// Production
const gateway = new StripePaymentGateway(stripe);
const service = new PaymentService(gateway);

// Test
const mockGateway = new MockPaymentGateway();
const testService = new PaymentService(mockGateway);

Контейнер зависимостей (DI Container)

Для больших проектов используют DI Container:

// inversify.ts
import { Container, injectable, inject } from 'inversify';

const container = new Container();

// Регистрируем зависимости
container.bind<Database>('Database')
  .to(Database)
  .inSingletonScope();  // Один instance на всё приложение

container.bind<Redis>('Cache')
  .to(Redis)
  .inSingletonScope();

container.bind<IEmailService>('EmailService')
  .to(SMTPEmailService);

container.bind<UserService>('UserService')
  .to(UserService);

// Использование
const userService = container.get<UserService>('UserService');
// Контейнер автоматически создаёт все зависимости!

Реальные примеры проблем которые решает DI

Проблема 1: Утечки памяти (без DI)

// БЕЗ DI
class Service1 {
  constructor() {
    this.db = new Database();  // Создаёт новый instance
  }
}

class Service2 {
  constructor() {
    this.db = new Database();  // Создаёт НОВЫЙ instance (утечка!)
  }
}

const s1 = new Service1();
const s2 = new Service2();
// Два процесса БД вместо одного = утечка памяти!

// С DI
const db = new Database();  // Один instance
const s1 = new Service1(db);
const s2 = new Service2(db);
// Две сервиса используют один процесс = OK

Проблема 2: Race conditions (без DI)

// БЕЗ DI
class AuthService {
  private static instance: AuthService;
  
  static getInstance() {
    if (!this.instance) {
      this.instance = new AuthService();
    }
    return this.instance;
  }
}

// Тест 1:
process.env.JWT_SECRET = 'test-secret-1';
const auth1 = AuthService.getInstance();

// Тест 2 (одновременно):
process.env.JWT_SECRET = 'test-secret-2';
const auth2 = AuthService.getInstance();

// auth1 и auth2 — ОДИНАКОВЫЕ! Используют тот же secret!
// Тест 2 нарушил тест 1!

// С DI
const auth1 = new AuthService(new JWTService('test-secret-1'));
const auth2 = new AuthService(new JWTService('test-secret-2'));
// Разные instance, разные configuration

Правила хорошего DI

1. Inject interfaces, не implementation

// ❌ Плохо
class Service {
  constructor(private db: PostgreSQL) {}
}

// ✅ Хорошо
interface IDatabase {
  query(sql: string): Promise<any>;
}

class Service {
  constructor(private db: IDatabase) {}
}

2. Constructor injection, не property injection

// ❌ Плохо
class Service {
  db: Database;
  
  setDatabase(db: Database) {
    this.db = db;  // Когда db undefined?
  }
}

// ✅ Хорошо
class Service {
  constructor(private db: Database) {}  // Сразу известна зависимость
}

3. Не inject слишком много

// ❌ Плохо (God Object)
class UserService {
  constructor(
    private db: Database,
    private cache: Redis,
    private email: EmailService,
    private sms: SMSService,
    private push: PushService,
    private analytics: Analytics,
    private logger: Logger,
    private config: Config,
    private validator: Validator,
    // ... 20+ параметров
  ) {}
}

// ✅ Хорошо
class UserService {
  constructor(
    private db: Database,
    private notificationService: INotificationService
  ) {}
}

class NotificationService implements INotificationService {
  constructor(
    private email: EmailService,
    private sms: SMSService,
    private push: PushService
  ) {}
}

Итого: практическая ценность DI

DI оберегает от:

✅ Невозможности тестирования → Можно мокировать всё ✅ Плотной связанности → Легко менять реализацию ✅ Дублирования кода → DRY принцип ✅ Утечек памяти → Shared instances ✅ Race conditions → Изоляция состояния ✅ Сложности расширения → Добавь новую зависимость ✅ Configuration hell → Одно место для config ✅ Невозможности переиспользования → Reusable components

Инвестиция в DI окупается в:

• Тестировании (экономия часов на debugging)
• Рефакторинге (безопасные изменения)
• Масштабировании (легко добавлять feature)
• Поддержке (новички быстро разбираются)

DI — это не overhead, а инвестиция в качество.