На протяжении всего курса мы уже не раз создавали классы, связывали их между собой, передавали один объект в другой — то через параметры методов, то через конструктор, то через свойства. Мы работали с ассоциациями, композицией, агрегацией, разбирали, как объекты взаимодействуют внутри системы. И всё это время мы фактически строили сеть связей между классами, даже если специально не задумывались об этом.

Сейчас, на этом этапе, самое время остановиться и посмотреть на эти связи чуть глубже. Ведь если подумать, у нас есть всего несколько способов связать два класса между собой:

Можно передать объект как параметр метода, получить зависимость через конструктор, выставить её через свойство, а можно создать объект прямо внутри класса с помощью оператора new.

Именно про последний вариант мы сегодня и поговорим. Ведь до этого момента все эти способы передачи зависимостей казались нам почти равнозначными. Но теперь, когда мы начинаем говорить уже об архитектуре, становится важно понимать: не все способы связать классы одинаково полезны. Более того — некоторые из них со временем превращаются в настоящие ловушки. Представим, что у нас есть довольно простой сервис, который обрабатывает заказ. Ничего сложного — просто создаёт заказ и записывает информацию в лог.

public class OrderService
{
    public void CreateOrder()
    {
        var logger = new FileLogger(); // зависимость создаётся внутри
        logger.Log("Создаём заказ...");

        Console.WriteLine("Заказ создан!");
        logger.Log("Заказ успешно создан.");
    }
}

public class FileLogger
{
    public void Log(string message)
    {
        File.AppendAllText("log.txt", message + "\n");
    }
}

Выглядит просто. Даже очень. Новичок скажет:

Ну и что? Я же просто создал логгер. Работает же!

И действительно — работает. Но давай посмотрим, какие проблемы скрыты внутри этого «простого» решения.

Когда внутри OrderService написано new FileLogger(), класс как бы говорит:

Мне нужен именно этот конкретный логгер. Я сам знаю, какой он должен быть. И менять я ничего не собираюсь.

И пока всё хорошо, пока ты действительно хочешь писать логи только в файл, проблем не видно. Код работает, всё предсказуемо. Но представь завтрашний день. Тебе говорят:

Теперь по требованиям безопасности логи должны отправляться в облако.

И вот с этого момента всё веселье и начинается. Класс упрямо создаёт FileLogger, потому что мы сами «вшили» эту зависимость внутрь. Он не может использовать другой логгер — он знает только один вариант.

Чтобы изменить способ логирования, тебе приходится лезть внутрь класса и переписывать код. Менять сам метод CreateOrder(), находить все места, где используется new FileLogger(), проверять, что нигде ничего не поломалось.

И здесь становится видно, что проблема не только в том, что мы создали логгер внутри класса. Мы невольно добавили OrderService лишнюю обязанность — он теперь отвечает не только за работу с заказами, но и за то, какой логгер использовать и как его создавать. Это уже нарушение SRP: у класса появилась вторая причина для изменения.

Кроме того, получается, что OrderService заранее «зашит» под конкретный FileLogger. Если завтра нам понадобится логировать в консоль, базу данных или внешнюю систему — изменить это без правки класса нельзя. Значит, мы нарушаем и принцип OCP. Из-за такой жёсткой привязки класс становится негибким: он строится вокруг деталей, а не вокруг абстракций.

И всё это — просто из-за одного new FileLogger() внутри метода. Такая проблема, конечно же, возникла не вчера. Как только системы начали расти, разработчики довольно быстро заметили: чем больше классов сами создают себе зависимости, тем меньше гибкости остаётся у всей архитектуры. Изменение одной маленькой детали часто приводило к «эффекту домино», когда приходилось переписывать кучу несвязанных на первый взгляд классов.

Со временем стало понятно, что это не просто случайная неприятность, а вполне закономерная проблема подхода, при котором объект сам решает, какие зависимости ему создавать. И программисты начали искать способ «развязать» систему, убрать жёсткие связи и научить классы работать через абстракции, а не через конкретные реализации.

Так появился ещё один важный архитектурный принцип — инверсия контроля, или Inversion of Control. Он формулирует очень простую, но мощную идею:

Именно этот принцип и стал фундаментом для всех современных подходов к гибкой архитектуре, включая тот, о котором мы скоро начнём говорить более детально — Dependency Injection.

У нас была ситуация, где OrderService сам создаёт FileLogger через new. Теперь мы сделаем наоборот: сервис перестанет создавать логгер сам и будет получать его снаружи — в готовом виде.

Сначала введём абстракцию для логгера:

public interface ILogger
{
    void Log(string message);
}

Сделаем файловый логгер реализацией этой абстракции:

public class FileLogger : ILogger
{
    public void Log(string message)
    {
        File.AppendAllText("log.txt", message + Environment.NewLine);
    }
}

А теперь перепишем сам OrderService так, чтобы он логгер не создавал, а принимал:

public class OrderService
{
    private readonly ILogger _logger;

    public OrderService(ILogger logger)
    {
        _logger = logger;
    }

    public void CreateOrder()
    {
        _logger.Log("Создаём заказ...");

        Console.WriteLine("Заказ создан!");

        _logger.Log("Заказ успешно создан.");
    }
}

Обрати внимание, что внутри класса больше нет new FileLogger(). OrderService больше не решает, какой именно логгер будет использоваться. Он просто говорит:

Мне нужен кто-то, кто умеет логировать. Остальное — не моя забота.

На самом деле мы с вами подсознательно делали такие вещи уже много раз, просто не называли их правильными словами. Когда мы старались следовать принципам SOLID, мы неоднократно создавали интерфейсы, абстракции, выносили детали наружу, чтобы не привязывать классы к конкретным реализациям. Это формализация того подхода, который вы уже начинали использовать. Инверсия контроля даёт нам идею — зависимость должна приходить извне. Но сама по себе идея не отвечает на практический вопрос:

А как именно передавать зависимости внутрь класса? Как это организовать системно, удобно и предсказуемо?

Вот именно на этот вопрос отвечает Dependency Injection, или сокращённо DI.

Если IoC — это философия, направление, мысль, то DI — это её практическое воплощение. Он говорит:

«Не создавай зависимости внутри — позволь внешнему коду внедрить их в тебя».

Причём внедрить можно разными способами: через конструктор, через метод, через свойство. DI не привязан к какому-то одному техническому приёму — это общий подход, который помогает программе правильно «складываться» из компонентов.

В самом простом виде DI — это то, что мы уже сделали:

var logger = new FileLogger();
var orderService = new OrderService(logger);

Мы вручную создали зависимость и передали её в класс. Это и есть DI в самом чистом виде.

Принцип инверсии контроля — это архитектурная идея, которая говорит нам очень простую вещь:

Класс не должен сам управлять своими зависимостями. Он не должен решать, что именно ему создавать и какой конкретный объект использовать. Это решение нужно перевернуть и вынести наружу.

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

Dependency Injection — это практический способ реализовать этот принцип. DI отвечает на вопрос «как конкретно передать зависимости извне»: через конструктор, через метод, через свойство — не важно. Главное, что класс получает готовые зависимости, а не создаёт их сам.

Если коротко: IoC — это идея. DI — это техника, с помощью которой эта идея воплощается в коде.