Как инверсия контроля связана с инверсией зависимости

Во многих статьях по всему миру термины «Инверсия управления» и «Принцип инверсии зависимостей», похоже, перепутаны и используются как синонимы (дальнейшая путаница обеспечивается инструментами, которые называются «DI-контейнеры» и «IoC-контейнеры»). Статья в Википедии делает хорошую работу, пытаясь объяснить, что IoC - это не то же самое, что DI:

Инверсия управления (IoC) описывает схему, в которой пользовательские части компьютерной программы получают поток управления из универсальной, многократно используемой библиотеки.

Таким образом, DIP означает, что ваши модули зависят от абстракций, а не от конкретных реализаций.

И IoC - это управление потоком программ для отдельного модуля. И одна из вещей, которую вы можете сделать этим модулем, это разрешить зависимости во время выполнения.

Это различие кажется справедливым, но я никогда не видел, чтобы кто-либо упоминал о других применениях принципа IoC, кроме разрешения зависимостей. Определение Википедии довольно широкое, и кажется, что вы могли бы сделать гораздо больше с модулем, который может делать вызовы в ваш пользовательский код на основе его конфигурации и некоторой внутренней логики.

Итак, вот некоторые вопросы, которые я пока не могу понять:

Какова реальная связь между IoC и DIP? Всегда ли IoC служит средством реализации DIP?
Почему инструменты для разрешения зависимостей называются DI- и IoC-контейнерами? Это означает, что DI и IoC - это одно и то же.

Примечание . Этот вопрос не является дубликатом раздела «В чем разница между DI и IoC» , поскольку последний задает вопрос о внедрении зависимости, а не об инверсии зависимости.

design-patterns inversion-of-control dependency-inversion

— Андре Борхес
источник

Возможный дубликат В чем разница между DI и IoC?

— комнат

@gnat, нет, это не так, пожалуйста, смотрите мои изменения

— Андре Борхес

согласен, я пропустил это извините

— комнат

ИМО, простой ответ "они одинаковы". IoC - это другое название для инверсии зависимостей, и оба являются способом достижения внедрения зависимости. Я вижу «инверсию зависимости» как глубоко бесполезный термин, поскольку его слишком легко спутать с инъекцией. Так что есть DI (инъекция), а IoC - это способ достижения инверсии зависимостей / управления через инъекцию.

— Дэвид Арно,

На сайте Мартина Фаулера есть отличная статья, в которой есть глава, посвященная разнице между DIP, DI и IoC . Суть этого (как скопировано с этого сайта)

DI о том, как один объект приобретает зависимость. Когда зависимость предоставляется извне, тогда система использует DI. IoC о том, кто инициирует вызов. Если ваш код инициирует вызов, это не IoC, если контейнер / система / библиотека выполняет обратный вызов кода, который вы предоставили, это IoC.

DIP, с другой стороны, касается уровня абстракции в сообщениях, отправляемых из вашего кода вызываемому объекту. Безусловно, использование DI или IoC с DIP имеет тенденцию быть более выразительным, мощным и выровненным по доменам, но они связаны с различными аспектами или силами в общей проблеме. DI - это проводка, IoC - направление, а DIP - форма.

— JDT
источник

IoC о том, кто инициирует вызов - кто инициирует вызов на что? Если я напишу ISomeInterface object = container.Resolve<ISomeInterface>()это IoC или нет?

— Андре Борхес

То, что вы пишете, является реализацией в шаблоне поиска службы. Это тоже IoC. Не IoC - это ISomeInterface object = new MyClass (). Таким образом, подразумеваемый вызов - это «призыв к реализации» (или кто называет «новым»).

— Sjoerd222888

«DIP, с другой стороны, касается уровня абстракции в сообщениях, отправляемых из вашего кода тому, что он вызывает». Это звучит как глупость для меня. Где в этом инверсия? Он описывает абстракцию зависимости, а не инверсию.

— Дэвид Арно,

@DavidArno, ты хочешь сказать, что мы не можем доверять сайту Мартина Фаулера?

— holdenmcgrohen

@holdenmcgrohen, это его мнение о вещах. Просто потому, что это Мартин Фаулер, не делает это фактом. Иногда он ошибается ИМО, например, в отношении «модели данных анемии». В остальное время его очень проницательно. В этом случае я думаю, что он тоже не прав, так как это не имеет смысла.

— Дэвид Арно,