Действительно ли Внедрение зависимости является шаблоном и, является этим он?

Это действительно не пример DI.

Причина в том, что вы упорядочиваете зависимости ( PlayerClient и PlayerSkinClient в вашем случае) вместо того, чтобы упорядочивать зависимости для вас (передаваемые контейнером при создании бетонного объекта). IPlayerService ). Это «инверсия управления» - у вас вызывается конструктор, вместо того, чтобы вызывать его. Это основная причина использования шаблона DI, и наличие контейнера, который определяет, разрешает и помещает зависимости в объекты, которые их запрашивают, является конкретным способом сделать это.

Когда вы позволяете контейнеру управлять передачей зависимостей, вам не нужно писать и поддерживать код, который передает зависимости конкретному IPlayerService . Это позволяет вам выполнять другие реализации PlayerClient и PlayerSkinClient (например, когда вы хотите имитировать их для построения тестов) и не обновлять код, который инициализирует IPlayerService . Вот почему полезен шаблон DI.

Итак, можно ли использовать DI как шаблон без каких-либо дополнительных рамок?

Да, безусловно.

Если да, то приведенный выше код является примером этого?

Да, безусловно.

И наконец, что определяет шаблон DI, если он существует, без понятия Контейнера.

Объекту дано все, от чего он зависит; ему вводятся его зависимости.

Вот некоторые другие статьи, которые могут привести некоторые другие важные детали по этому вопросу в порядке «в первую очередь следует прочитать»:

1. Dependency Injection Demystified ;
2. ​​Внедрение зависимости .

Прочитав их, я обнаружил, что лучше понимаю предмет.

По словам Мартина Фаулера, который в некоторой степени является экспертом в этой области, внедрение зависимостей - это другое название конкретной реализации абстрактной концепции, известной как инверсия управления ( полная статья ).

В своей основе все средства DI следующие: объекты, от которых зависит правильная работа класса, инициализируются и передаются в него извне, а не сам класс отвечает за получение / инициализацию этих объектов. Специфика того, как это достигается, выходит за рамки схемы.

IoC - это то же самое, но, как говорит Мартин Фаулер, выражение «инверсия управления» - очень тупой способ описания того, что происходит.

Лично я не думаю, что «Внедрение зависимостей» намного лучше. Я бы описал это как «правильное использование конструкторов».

Пример не-IoC / не-DI:

class Foo
{
    void DoSomething()
    {
        DbConnection myConnection = new DbConnection(ConfigurationSettings...);
        myConnection.ExecuteCommand();
    }
}

То же самое с использованием IoC / DI:

class Foo
{
    private DbConnection myConnection;

    public Foo(DbConnection conn)
    {
        myConnection = conn;
    }

    void DoSomething()
    {
        myConnection.ExecuteCommand();
    }
}

Я с уважением не согласен с теми, кто утверждает, что это не настоящий IoC / DI, если у вас нет явного связующего / ассемблера / что-то, что связывает внедренные типы с конкретными реализациями, потому что класс, получающий зависимости, не знает разницы. Независимо от того, упорядочиваете ли вы зависимости во внешнем классе или во внешнем файле конфигурации, это детали реализации.

Прочтите это: http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart1.aspx

1. Да, хотя по сравнению с чем-то вроде PicoContainer - или другими действительно крошечными контейнерами, все из которых протестированы и хорошо продуманы - в конечном итоге вы реализуете тот же набор функций. Лучшим примером этого является статья Ayende "Building an IoC container in 15 lines".

2. Пересмотрев свой ответ, я решил ответить "да". Я думаю, что основной когнитивный диссонанс здесь заключается в том, что из-за того, что разработчики путают тот факт, что многие/большинство DI/IoC-фреймворков предлагают аккуратные способы построения объектов, которые не выглядят как new, именно это заставляет их придерживаться идей IoC.

3. Как уже упоминалось, определение Мартина Фаулера является каноническим, и оно довольно хорошо освещено в других источниках.

Забавно то, что первый пример - это вообще не DI, а пример анти-паттерна Service Locator - ничего не вводится .

Ваш собственный пример - это чистый DI, а точнее реализация паттерна Constructor Injection .

DI - это не один шаблон, а набор шаблонов и принципов. Когда мы подключаем все зависимости вручную, мы обычно называем это Poor Man's DI . Другими словами, контейнеры DI не являются обязательными, но настоятельно рекомендуется:)

См. Также это описание того, что контейнер DI привносит в таблицу .