Как избавиться от жесткой зависимости от конкретной реализации (например, singleton)?

Жесткая зависимость от конкретного класса, особенно от Singleton, создает проблемы с тестированием и гибкостью системы, так как код становится тесно связанным с одной реализацией. Решением является применение принципа инверсии зависимостей (DIP), который гласит, что модули верхнего уровня не должны зависеть от модулей нижнего уровня, а оба должны зависеть от абстракций.

Основной подход: Внедрение зависимостей (Dependency Injection)

Вместо того чтобы класс создавал зависимость внутри себя, он должен получать её извне. Это можно сделать через конструктор (наиболее предпочтительный способ), через сеттер или через интерфейс. Рассмотрим пример на TypeScript.

// ПЛОХО: Жесткая зависимость от Singleton
class OrderService {
    private logger = Logger.getInstance(); // Прямое использование Singleton

    processOrder() {
        this.logger.log('Processing order...');
        // ... логика
    }
}

// ХОРОШО: Зависимость внедряется через конструктор
interface ILogger {
    log(message: string): void;
}

class ConsoleLogger implements ILogger {
    log(message: string) {
        console.log(`[LOG]: ${message}`);
    }
}

class OrderService {
    constructor(private logger: ILogger) {} // Зависимость предоставляется извне

    processOrder() {
        this.logger.log('Processing order...');
        // ... логика
    }
}

// Использование
const logger = new ConsoleLogger();
const orderService = new OrderService(logger);
orderService.processOrder();

// Для тестирования легко подменить реализацию
class MockLogger implements ILogger {
    log(message: string) {
        // Ничего не делаем, или записываем в массив для проверки
    }
}
const testService = new OrderService(new MockLogger());

Где и как это применяется

Этот подход широко используется в современных фреймворках (Angular, NestJS, Spring). Контейнеры внедрения зависимостей (IoC-контейнеры) автоматически управляют созданием и связыванием объектов. В приведенном примере OrderService теперь зависит от абстракции ILogger, а не от конкретного Logger. Это позволяет:

• Легко тестировать класс, подменяя зависимости mock-объектами.
• Менять реализацию (например, заменить консольный логгер на файловый или Sentry) без изменения кода OrderService.
• Соблюдать принцип единственной ответственности (SRP) — класс не занимается созданием своих зависимостей.

Вывод: Применяйте внедрение зависимостей через абстракции (интерфейсы или абстрактные классы) везде, где возможны изменения реализации или требуется изолированное тестирование. Это особенно важно для сервисов, работающих с внешними системами (базы данных, API, логирование).