Как работает контейнер внедрения зависимостей?

Question

[Дмитрий Макаров]

Объясните, пожалуйста, "на пальцах" как работает контейнер внедрения зависимостей.
Никак не могу вникнуть в эту идею....

Как я понимаю:
Есть некоторый механизм, которому доверили следить за созданием объектов и, когда нужно, подсовывать либо вновь созданный объект, либо уже когда то созданный.
Есть простые объекты, которые ни от кого не зависят.
Есть сложные объекты, в которых есть зависимости.

Я правильно понимаю, что сложные объекты будут зависеть от контейнера внедрения зависимостей?
Или контейнер внедрения зависимости при конфигурировании узнает про все необходимое для создания объектов и при необходимости выдает уже сконфигурированные объекты?

Не могли бы вы привести какой-нибудь сферический пример в вакууме?
Интересно, прежде всего посмотреть, на EntryPoint программы: как инстанцируется и конфигурируется сам контейнер внедрения.

Comments

[Сергей Соколов]

IoC, DI, IoC-контейнер — Просто о простом – на Хабре.

[Дмитрий Макаров]

Сергей Соколов: я видел это....не понятно.....

2. Создаем сам контейнер, указывая его конфигуратор:

IKernel ninjectKernel = new StandardKernel(new SimpleConfigModule());
// там где нужно создать экземпляр ScheduleViewer мы вместо new, делаем так:
ScheduleViewer scheduleViewer= ninjectKernel.Get();

Контейнер сам создаст экземпляр класса ScheduleManager, вызовет конструктор ScheduleViewer и подставит в него свежесозданный экземпляр ScheduleManager.

то есть теперь везде где нам надо использовать зависимость нам надо пропихивать этот ninject?
то есть раньше мы зависели от ScheduleManager, сейчас зависим от ninject? шило на мыло, не?

допустим на этапе инициализаций мы с помощью контейнера отпределили все реализации интерфейсов и инстанцировали все объекты ....тут не надо прокидывать зависимость от контейнера в класс использующий зависимости. А если объект нельзя создать сразу при инициализации приложения? Если реализация выбирается динамически в зависимости от каких-то условий при работе программы: паттерн стратегия, например? Тут как?

и как объяснить ninject`у что вот для этого экземпляра класса X нам нужна Y1-реализация интерфейса IY, а для другого экземпляра экземпляра класса X нам нужна Y2-реализация интерфейса IY?

[Дмитрий Макаров]

Я могу представить способ отложенной инициализации зависимостей, не завязываясь жестко на IoC-контейнер....через делегат. То есть мы в сложный объект передаем не саму зависимость, а способ ее создания, когда будет нужно. Но в таком случае сложный объект должен поддерживать такой сценарий создания объекта зависимости. То есть с произвольным объектом такое не пройдет?