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

Ответ 1

IoC - это общий термин, означающий, что приложение не вызывает методы в платформе, а платформа вызывает реализации, предоставляемые приложением.

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

Например, IoC без использования DI будет шаблоном шаблона, потому что реализация может быть изменена только посредством подклассов.

DI Frameworks предназначены для использования DI и могут определять интерфейсы (или аннотации в Java), чтобы упростить передачу реализаций.

Контейнеры IoC - это структуры DI, которые могут работать за пределами языка программирования. В некоторых вы можете настроить, какие реализации использовать в файлах метаданных (например, XML), которые являются менее инвазивными. С некоторыми вы можете сделать IoC, что обычно невозможно, например, внедрить реализацию в pointcuts.

Смотрите также эту статью Мартина Фаулера.

Ответ 2

Короче говоря, IoC - это гораздо более широкий термин, который включает, но не ограничивается этим, DI

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

До того, как у DI было имя, люди начали ссылаться на фреймворки, которые управляют зависимостями как инверсия контрольных контейнеров, и вскоре значение IoC постепенно приближалось к этому конкретному значению: инверсия контроля над зависимостями.

Инверсия управления (IoC) означает, что объекты не создают другие объекты, на которые они полагаются, чтобы выполнять свою работу. Вместо этого они получают объекты, которые им нужны из внешнего источника (например, файл конфигурации xml).

Injection Dependency (DI) означает, что это делается без вмешательства объекта, обычно с помощью компонента framework, который передает параметры конструктора и устанавливает свойства.

Ответ 3

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

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

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

Ответ 4

источник

IoC (я nversion о т C ontrol): - Его общий термин и реализованы несколько способов (события, делегаты и т.д.).

DI (D ependency I njection): - DI является подтипом IoC и реализуется путем инъекции конструктора, сеттер инъекции или инъекции интерфейса.

Но Spring поддерживает только следующие два типа:

• Сеттер Инъекция
  • DI, основанный на установщике, реализуется путем вызова методов сеттера на бинах пользователей после вызова конструктора без аргументов или статического метода фабрики без аргументов для создания экземпляра их бина.
• Конструктор Инъекция
  • DI на основе конструктора реализуется путем вызова конструктора с несколькими аргументами, каждый из которых представляет коллаборатора. Используя это, мы можем проверить, что внедренные bean-компоненты не равны null и не работают быстро (дают сбой во время компиляции, а не во время выполнения), поэтому при запуске самого приложения мы получаем NullPointerException: bean does not exist. Внедрение в конструктор - это лучшая практика для внедрения зависимостей.

Ответ 5

IOC (Inversion Of Controller). Предоставление управления контейнеру для получения экземпляра объекта называется Inversion of Control. означает вместо того, чтобы вы создавали объект с помощью нового оператора, пусть контейнер сделает это за вас.

DI (инъекция зависимостей). Способ ввода свойств объекту называется инъекцией зависимостей.

We have three types of Dependency injection
    1)  Constructor Injection
    2)  Setter/Getter Injection
    3)  Interface Injection

Spring будет поддерживать только инжекцию конструктора и инъекцию Setter/Getter.

Ответ 6

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

Предположим, что мы создаем приложение, которое содержит функцию отправки сообщений подтверждения SMS после отправки заказа. У нас будет два класса: один отвечает за отправку SMS (SMSService), а другой отвечает за захват пользовательских входов (UIHandler), наш код будет выглядеть следующим образом:

public class SMSService
{
    public void SendSMS(string mobileNumber, string body)
    {
        SendSMSUsingGateway(mobileNumber, body);
    }

    private void SendSMSUsingGateway(string mobileNumber, string body)
    {
        /*implementation for sending SMS using gateway*/
    }
}

public class UIHandler
{
    public void SendConfirmationMsg(string mobileNumber)
    {
        SMSService _SMSService = new SMSService();
        _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
    }
}

Выше реализации не ошибается, но есть несколько проблем:
-) Предположим, что в среде разработки вы хотите сохранить SMS-сообщения, отправленные в текстовый файл, вместо использования шлюза SMS, для этого; мы в конечном итоге изменим конкретную реализацию (SMSService) с другой реализацией, мы теряем гибкость и вынуждены переписывать код в этом случае.
-) Ну, в конечном итоге смешайте обязанности классов, наш (UIHandler) никогда не должен знать о конкретной реализации (SMSService), это нужно делать за пределами классов, используя "Интерфейсы". Когда это будет реализовано, это даст нам возможность изменить поведение системы путем замены (SMSService), используемого с другой макетной службой, которая реализует один и тот же интерфейс, эта служба будет сохранять SMS-сообщения в текстовый файл вместо отправки на mobileNumber.

Чтобы устранить указанные выше проблемы, мы используем интерфейсы, которые будут реализованы нашими (SMSService) и новыми (MockSMSService), в основном новый интерфейс (ISMSService) будет выставлять одинаковое поведение обеих служб в виде кода ниже:

public interface ISMSService
{
    void SendSMS(string phoneNumber, string body);
}

Затем мы изменим нашу (SMSService) реализацию для реализации интерфейса (ISMSService):

public class SMSService : ISMSService
{
    public void SendSMS(string mobileNumber, string body)
    {
        SendSMSUsingGateway(mobileNumber, body);
    }

    private void SendSMSUsingGateway(string mobileNumber, string body)
    {
        /*implementation for sending SMS using gateway*/
        Console.WriteLine("Sending SMS using gateway to mobile: 
        {0}. SMS body: {1}", mobileNumber, body);
    }
}

Теперь мы сможем создать новую макетную службу (MockSMSService) с совершенно другой реализацией, используя тот же интерфейс:

public class MockSMSService :ISMSService
{
    public void SendSMS(string phoneNumber, string body)
    {
        SaveSMSToFile(phoneNumber,body);
    }

    private void SaveSMSToFile(string mobileNumber, string body)
    {
        /*implementation for saving SMS to a file*/
        Console.WriteLine("Mocking SMS using file to mobile: 
        {0}. SMS body: {1}", mobileNumber, body);
    }
}

В этот момент мы можем изменить код в (UIHandler), чтобы использовать конкретную реализацию службы (MockSMSService) легко, как показано ниже:

public class UIHandler
{
    public void SendConfirmationMsg(string mobileNumber)
    {
        ISMSService _SMSService = new MockSMSService();
        _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
    }
}

Мы достигли большой гибкости и реализовали разделение проблем в нашем коде, но все же нам нужно сделать изменения на базе кода, чтобы переключаться между двумя службами SMS. Поэтому нам нужно реализовать Injection Dependency.

Чтобы достичь этого, нам необходимо реализовать изменение в нашем конструкторе класса (UIHandler), чтобы передать через него зависимость, выполнив это, код, который использует (UIHandler), может определить, какую конкретную реализацию (ISMSService) использовать

public class UIHandler
{
    private readonly ISMSService _SMSService;

    public UIHandler(ISMSService SMSService)
    {
        _SMSService = SMSService;
    }

    public void SendConfirmationMsg(string mobileNumber)
    {
        _SMSService.SendSMS(mobileNumber, "Your order has been shipped successfully!");
    }
}

Теперь форма пользовательского интерфейса, которая будет разговаривать с классом (UIHandler), отвечает за передачу какой-либо реализации интерфейса (ISMSService) для использования. Это означает, что мы инвертировали элемент управления, (UIHandler) больше не отвечает, чтобы решить, какую реализацию использовать, вызывающий код делает. Мы реализовали принцип инверсии управления, который является одним из его типов.

Код формы пользовательского интерфейса будет выглядеть следующим образом:

class Program
{
    static void Main(string[] args)
    {
        ISMSService _SMSService = new MockSMSService(); // dependency

        UIHandler _UIHandler = new UIHandler(_SMSService);
        _UIHandler.SendConfirmationMsg("96279544480");

        Console.ReadLine();
    }
}

Ответ 7

Но весенняя документация говорит, что они одинаковы.

http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-introduction

В первой строке "IoC также известен как внедрение зависимостей (DI)".

Ответ 8

IoC. Инверсия управления - это общий термин, независимо от языка, он фактически не создает объекты, а описывает, в каком объекте моды создается.

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

Ответ 9

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

Существует несколько базовых методов для реализации инверсии управления. Это:

• Использование шаблона factory
  
• Использование шаблона локатора службы
• Использование инъекции зависимостей любого типа ниже:
  
  1). Инъектор конструктора
  2). Инжекторы сеттеров
  3). Инъекция интерфейса

Ответ 10

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

Основные задачи, выполняемые контейнером IoC: для создания экземпляра класса приложения. для настройки объекта. для сборки зависимостей между объектами.

DI - это процесс обеспечения зависимостей объекта во время выполнения с помощью инъекции установщика или инъекции конструктора.

Ответ 11

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();
}

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

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

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

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

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

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

Разница между инверсией контроля и инъекцией зависимости

Ответ 12

IOC (Inversion of Control) - это в основном концепция шаблона проектирования для удаления зависимостей и их развязки, чтобы сделать поток нелинейным и позволить контейнеру/или другому объекту управлять предоставлением зависимостей. Он фактически следует за Голливудским директором "Не звоните нам, мы позвоним вам".  Итак, суммируя различия.

Инверсия управления: - его общий термин для развязки зависимостей и делегирования их подготовки, и это может быть реализовано несколькими способами (событиями, делегатами и т.д.).

Инъекция зависимостей: - DI является подтипом IOC и реализуется путем инъекции конструктора, инъекции установщика или инъекции метода.

В этой статье описывается это очень аккуратно.

https://www.codeproject.com/Articles/592372/Dependency-Injection-DI-vs-Inversion-of-Control-IO

Ответ 13

Inversion of Control - это общий принцип проектирования архитектуры программного обеспечения, который помогает создавать модульные программные структуры многократного использования, которые просты в обслуживании.

Это принцип разработки, при котором поток управления "принимается" из общей библиотеки или кода многократного использования.

Чтобы понять это лучше, давайте посмотрим, как мы использовали кодирование в наши ранние дни кодирования. В процедурных/традиционных языках бизнес-логика, как правило, контролирует поток приложения и "вызывает" общий или повторно используемый код/​​функции. Например, в простом консольном приложении мой поток управления контролируется инструкциями моей программы, которые могут включать в себя вызовы некоторых общих функций многократного использования.

print ("Please enter your name:");
scan (&name);
print ("Please enter your DOB:");
scan (&dob);

//More print and scan statements
<Do Something Interesting>

//Call a Library function to find the age (common code)
print Age

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

Например, в системе на основе Windows уже будет доступна инфраструктура для создания элементов пользовательского интерфейса, таких как кнопки, меню, окна и диалоговые окна. Когда я пишу бизнес-логику своего приложения, это будут каркасные события, которые будут вызывать мой код бизнес-логики (когда событие запускается), а НЕ наоборот.

Хотя код платформы не знает о моей бизнес-логике, он все равно будет знать, как вызывать мой код. Это достигается с помощью событий/делегатов, обратных вызовов и т.д. Здесь управление потоком является "инвертированным".

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

Внедрение зависимостей - это шаблон проектирования, который реализует принцип IoC для разрешения зависимостей объектов.

Проще говоря, когда вы пытаетесь написать код, вы будете создавать и использовать разные классы. Один класс (класс A) может использовать другие классы (класс B и/или D). Итак, класс B и D являются зависимостями класса A.

Простая аналогия будет классом автомобилей. Автомобиль может зависеть от других классов, таких как двигатель, шины и многое другое.

Внедрение зависимостей предполагает, что вместо зависимых классов (здесь Class Car), создающих свои зависимости (Class Engine и класс Tire), класс должен быть внедрен с конкретным экземпляром зависимости.

Давайте разберемся с более практичным примером. Учтите, что вы пишете свой собственный TextEditor. Среди прочего, вы можете иметь проверку орфографии, которая предоставляет пользователю возможность проверить опечатки в его тексте. Простая реализация такого кода может быть:

Class TextEditor
{

    //Lot of rocket science to create the Editor goes here

    EnglishSpellChecker objSpellCheck;
    String text;

    public void TextEditor()

    {   

        objSpellCheck = new EnglishSpellChecker();

    }

    public ArrayList <typos> CheckSpellings()
    {

        //return Typos;

    }

}

На первый взгляд все выглядит радужно. Пользователь напишет какой-нибудь текст. Разработчик захватит текст и вызовет функцию CheckSpellings и найдет список опечаток, которые он покажет пользователю.

Кажется, все работает отлично, пока в один прекрасный день один пользователь не начнет писать по-французски в редакторе.

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

Здесь мы создали тесно связанный код с "английским" SpellChecker, тесно связанным с нашим классом TextEditor, что означает, что наш класс TextEditor зависит от EnglishSpellChecker или, другими словами, EnglishSpellCheker является зависимостью для TextEditor. Нам нужно удалить эту зависимость. Кроме того, нашему текстовому редактору нужен способ хранить конкретную ссылку на любую проверку орфографии, основанную на усмотрении разработчика во время выполнения.

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

interface ISpellChecker
{

    Arraylist<typos> CheckSpelling(string Text);

}

Class EnglishSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}



Class FrenchSpellChecker : ISpellChecker

{

    public override Arraylist<typos> CheckSpelling(string Text)

    {

        //All Magic goes here.

    }

}

В нашем примере класс TextEditor должен получить конкретный экземпляр типа ISpellChecker.

Теперь зависимость может быть введена в Constructor, Public Property или метод.

Давайте попробуем изменить наш класс, используя Constructor DI. Измененный класс TextEditor будет выглядеть примерно так:

Class TextEditor

{

    ISpellChecker objSpellChecker;

    string Text;



    public void TextEditor(ISpellChecker objSC)

    {

        objSpellChecker = objSC;

    }



    public ArrayList <typos> CheckSpellings()

    {

        return objSpellChecker.CheckSpelling();

    }

}

Чтобы вызывающий код при создании текстового редактора мог внедрить соответствующий тип SpellChecker в экземпляр TextEditor.

Вы можете прочитать полную статью здесь

Ответ 14

IOC (Inversion Of Control): Предоставление контроля контейнеру для получения экземпляра объекта называется Inversion of Control. Это означает, что вместо того, чтобы создавать объект с помощью оператора new, пусть контейнер сделает это за вас.

DI (Dependency Injection). Передача необходимых параметров (свойств) из XML в объект (в POJO CLASS) называется внедрением Dependency Injection.

Ответ 15

Начнем с 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.

Ответ 16

//ICO, DI, 10 лет назад, это было так:

public class  AuditDAOImpl implements Audit{

    //dependency
    AuditDAO auditDAO = null;
        //Control of the AuditDAO is with AuditDAOImpl because its creating the object
    public AuditDAOImpl () {
        this.auditDAO = new AuditDAO ();
    }
}

Теперь с Spring 3,4 или последним, как показано ниже

public class  AuditDAOImpl implements Audit{

    //dependency

     //Now control is shifted to Spring. Container find the object and provide it. 
    @Autowired
    AuditDAO auditDAO = null;

}

В целом элемент управления инвертируется от старой концепции связанного кода с такими фреймворками, как Spring, что делает объект доступным. Так что IOC, насколько я знаю, и инъекция зависимостей, как вы знаете, когда мы вставляем зависимый объект в другой объект, используя конструктор или сеттеры. Inject в основном означает передачу его в качестве аргумента. В Spring мы имеем конфигурацию на основе XML и аннотаций, где мы определяем объект bean и передаем зависимый объект с помощью стиля инсталляции Constructor или setter.

Ответ 17

Я нашел лучший пример на Dzone.com, который действительно полезен для понимания реальных различий между IOC и DI.

"IoC - это когда кто-то еще создает объекты для вас". Таким образом, вместо того, чтобы писать "новое" ключевое слово (например, MyCode c = new MyCode()) в вашем коде, объект создается кем-то другим. Этот "кто-то еще" обычно называют контейнером IoC. Это означает, что мы передаем rrsponsibility (control) контейнеру, чтобы получить экземпляр объекта, называемый Inversion of Control., Означает, что вместо того, чтобы создавать объект с помощью оператора new, пусть контейнер сделает это за вас.

   DI(Dependency Injection):  Way of injecting properties to an object is 
   called 
  Dependency injection.
   We have three types of Dependency injection
    1)  Constructor Injection
    2)  Setter/Getter Injection
    3)  Interface Injection
   Spring will support only Constructor Injection and Setter/Getter Injection.

Читать всю статью IOC и Читать всю статью DI

Ответ 18

1) DI is Child-> obj зависит от parent-obj. Глагол зависит важно. 2) МОК Child-> obj выполняет под платформой. где платформой может быть школа, колледж, танцевальный класс. Здесь выполняются действия с различными последствиями под любым поставщиком платформы.

практический пример:

//DI
child.getSchool();
//IOC
child.perform()// is a stub implemented by dance-school
child.flourish()// is a stub implemented by dance-school/school/

'

-AB

Ответ 19

Что касается этого вопроса, я бы сказал, что вики уже предоставила подробные и понятные объяснения. Я просто процитирую наиболее значимые здесь.

Внедрение IoC

В объектно-ориентированном программировании есть несколько основных методов для реализации инверсии управления. Это:

1. Использование шаблона сервисного локатора Использование внедрения зависимостей, например, инъекция в конструктор.
2. Использование контекстного поиска;
3. Использование шаблонного метода проектирования шаблона;
4. Использование шаблона проектирования стратегии

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

Внедрение зависимостей - это метод, при котором один объект (или статический метод) предоставляет зависимости другого объекта. Зависимость - это объект, который можно использовать (сервис). Инъекция - это передача зависимости зависимому объекту (клиенту), который будет ее использовать.

Ответ 20

Инверсия зависимостей: зависит от абстракций, а не от конкреций.

Инверсия управления: главное против абстракции и то, как главное - это клей систем.

Вот несколько хороших постов, рассказывающих об этом:

https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/

https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/

https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/

Ответ 21

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

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

В этом смысле DI - это не то же самое, что IoC, поскольку речь идет не о потоке control-, однако это своего рода Io *, то есть инверсия владения созданием объекта.

Что не так в моем объяснении DI и IoC?