Зачем нужно внедрение зависимостей (Dependency Injection)?

Внедрение зависимостей (DI) — это техника, при которой объект получает свои зависимости извне, а не создаёт их сам. Основная цель — сделать код слабо связанным, тестируемым и гибким к изменениям. Без DI классы жёстко привязаны к конкретным реализациям, что усложняет модификацию и тестирование.

Рассмотрим пример на C#. Без DI класс OrderService сам создаёт EmailSender:

public class OrderService {
    private EmailSender _sender = new EmailSender();
    
    public void Process(Order order) {
        // ...
        _sender.Send(order.Email, "Order processed");
    }
}

Здесь OrderService жёстко зависит от конкретного класса EmailSender. Если нужно заменить отправку на SMS или добавить логгирование, придётся менять код OrderService. Тестировать тоже сложно: нельзя подменить EmailSender на мок.

С DI через абстракцию (интерфейс) проблема решается:

public interface INotifier {
    void Send(string to, string message);
}

public class OrderService {
    private readonly INotifier _notifier;
    
    public OrderService(INotifier notifier) {
        _notifier = notifier;
    }
    
    public void Process(Order order) {
        // ...
        _notifier.Send(order.Email, "Order processed");
    }
}

Теперь OrderService не знает, какая конкретная реализация будет использована. В тестах мы передаём мок INotifier, а в продакшене — реальный EmailSender или SmsNotifier. Это даёт три ключевых преимущества:

• Тестируемость: зависимости легко заменяются на моки/стабы, что позволяет писать юнит-тесты без поднятия базы или внешних сервисов.
• Гибкость: можно менять поведение системы, подключая разные реализации (например, переключение между SMTP и SendGrid без изменения бизнес-логики).
• Упрощение изменений: при добавлении нового способа уведомлений не нужно трогать OrderService — только добавить класс, реализующий INotifier.

DI-контейнеры (Autofac, Unity, встроенный в ASP.NET Core) автоматизируют создание объектов и управление их временем жизни. Но сам принцип важен и без контейнеров — достаточно передавать зависимости через конструктор. Это стандарт для enterprise-приложений, где модульность и поддерживаемость критичны.