Инверсия контроля против внедрения зависимости

Давайте начнем с D SOLID и посмотрим на DI и IoC из книги Скотта Миллета «Профессиональные шаблоны проектирования ASP.NET»:

Принцип обращения зависимостей (DIP)

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

Внедрение зависимостей (DI) и инверсия управления (IoC)

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

В IoC поток управления системой инвертирован по сравнению с процедурным программированием. Примером этого является контейнер IoC , целью которого является внедрение сервисов в клиентский код без указания клиентским кодом конкретной реализации. В этом случае управление, которое инвертируется, является действием клиента, получающего услугу.

Millett, C (2010). Профессиональные шаблоны проектирования ASP.NET. Wiley Publishing. 7-8.

DI и IOC - это две схемы проектирования , которые в основном направлены на обеспечение слабой связи между компонентами , или просто способ, которым мы отделяем обычные отношения зависимости между объектами, чтобы объекты не были тесно связаны друг с другом.

На следующих примерах я пытаюсь объяснить обе эти концепции.

Ранее мы писали код, подобный этому

Public MyClass{
 DependentClass dependentObject
 /*
  At somewhere in our code we need to instantiate 
  the object with new operator  inorder to use it or perform some method.
  */ 
  dependentObject= new DependentClass();
  dependentObject.someMethod();
}

С внедрением Dependency, инжектор зависимостей позаботится о создании объектов

Public MyClass{
 /* Dependency injector will instantiate object*/
 DependentClass dependentObject

 /*
  At somewhere in our code we perform some method. 
  The process of  instantiation will be handled by the dependency injector
 */ 

  dependentObject.someMethod();
}

Вышеописанный процесс предоставления контроля другому (например, контейнеру) для создания экземпляра и внедрения можно назвать Inversion of Control, а процесс, в котором контейнер IOC вводит зависимость для нас, можно назвать внедрением зависимости.

IOC - это принцип, в котором управляющий поток программы инвертируется: вместо программиста, управляющего потоком программы , программа управляет потоком, уменьшая накладные расходы для программиста. Процесс, используемый программой для внедрения зависимости, называется DI

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

Также рекомендую к прочтению.

Что такое внедрение зависимостей?

Вы также можете проверить один из моих похожих ответов здесь

Разница между Inversion of Control & amp; Внедрение зависимостей

DI является подмножеством IoC

• IoC означает, что объекты не создают другие объекты, на которые они полагаются при выполнении своей работы. Вместо этого они получают нужные им объекты из внешнего сервиса (например, файла XML или отдельного сервиса приложения). Я использую две реализации IoC: DI и ServiceLocator.
• DI означает, что принцип IoC получения зависимого объекта выполняется без использования конкретных объектов, но абстракций (интерфейсов). Это делает все компоненты цепочки тестируемыми, потому что компонент более высокого уровня не зависит от компонента более низкого уровня, только от интерфейса. Максы реализуют эти интерфейсы.

Вот некоторые другие методы для достижения IoC .

Я думаю, что идея может быть продемонстрирована ясно, не входя в Объектно-ориентированные сорняки, которые, кажется, запутывают идею.

// dependency injection
function doSomething(dependency) {
    // do something with your dependency
}

// in contrast to creating your dependencies yourself
function doSomething() {
    dependency = getDependencySomehow()
}

// inversion of control
application = makeApp(authenticate, handleRequest, sendResponse)
application.run(getRequest())

// in contrast to direct control or a "library" style
application = makeApp()
request = application.getRequest()

if (application.authenticate(request.creds)) {
    response = application.handleRequest(request)
    application.sendResponse(response)
}

при наклоне головы и косоглазия глаза Вы будете видеть, что DI является конкретной реализацией МОК с определенными проблемами. Вместо того, чтобы ввести модели и поведения в среду разработки приложения или операцию высшего порядка, Вы вводите переменные в функцию или объект.