Что такое инверсия управления?

голоса
1k

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

  1. Что это?
  2. Какие проблемы он решает?
  3. Когда уместно, а когда нет?
Задан 06/08/2008 в 04:35
источник пользователем
На других языках...                            


32 ответов

голоса
1k

Инверсия управления (IoC) и Dependency Injection (DI) модели все об удалении зависимости от вашего кода.

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

public class TextEditor {

    private SpellChecker checker;

    public TextEditor() {
        this.checker = new SpellChecker();
    }
}

То , что мы сделали здесь , создает зависимость между TextEditorи SpellChecker. В сценарии IoC мы вместо того, чтобы сделать что - то вроде этого:

public class TextEditor {

    private IocSpellChecker checker;

    public TextEditor(IocSpellChecker checker) {
        this.checker = checker;
    }
}

В первом примере кода мы инстанцировании SpellChecker( this.checker = new SpellChecker();), что означает , что TextEditorкласс напрямую зависит от SpellCheckerкласса.

Во втором примере коды мы создаем абстракцию, имея SpellCheckerкласс зависимостей в TextEditorконструкторе подписи (не инициализирующую зависимости в классе). Это позволяет вызвать зависимость затем передать его в класс TextEditor как так:

SpellChecker sc = new SpellChecker; // dependency
TextEditor textEditor = new TextEditor(sc);

Теперь клиент создает TextEditorкласс имеет контроль над которым SpellCheckerреализация использовать , потому что мы инъекционную зависимость к TextEditorподписи.

Это лишь простой пример, есть хорошая серия статей Симоны Busoli , что объясняет его более подробно.

Ответил 06/08/2008 в 08:22
источник пользователем

голоса
485

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

Например, в старом меню школы, вы можете иметь:

print "enter your name"
read name
print "enter your address"
read address
etc...
store in database

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

В программе графического интерфейса пользователя или сконвертировано, а мы говорим,

when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase

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

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

Ответил 06/08/2008 в 06:42
источник пользователем

голоса
356

Что такое инверсия управления?

Если вы будете следовать этим простым два шага, вы сделали инверсию управления:

  1. Раздельное , что -в-делать часть из когда -в-не разлучит.
  2. Убедитесь в том, что , когда часть знает , как мало , насколько это возможно о какой части; и наоборот.

Есть несколько методов, возможных для каждого из этих этапов, основанных на технологии / язык вы используете для реализации.

-

Инверсия часть Инверсии управления (IoC) является запутанной вещью; из - за инверсии это относительный термин. Лучший способ понять IoC, чтобы забыть об этом слове!

-

Примеры

  • Обработка событий. Обработчики событий (то, что состоятельная часть) - Поднятие Событие (когда состоятельной часть)
  • Интерфейсы. клиентский компонент (когда состоятельная часть) - реализации компонентов интерфейса (то, что состоятельная часть)
  • XUnit fixure. Установка и демонтаж (что состоятельная часть) - рамки XUnit вызовов установки в начале и Teardown в конце (когда состоятельная часть)
  • Шаблон Метод шаблон проектирования. шаблонный метод, когда состоятельная часть - примитивные реализации подкласса, что состоятельная часть
  • Методы контейнера DLL в COM. DllMain, DllCanUnload и т.д. (что состоятельная часть) - COM / OS (когда-к делать часть)
Ответил 22/07/2010 в 18:34
источник пользователем

голоса
81

Инверсия управления о отделяя проблемы.

Без IoC : У вас есть ноутбук компьютер и вы случайно разбить экран. И штопка, вы найдете тот же экран модели ноутбука нет нигде на рынке. Таким образом , вы застряли.

С IoC : У вас есть настольный компьютер , и вы случайно разбить экран. Вы находите , что Вы можете просто захватить практически любой настольный монитор с рынка, и он хорошо работает с настольным компьютером.

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

Ответил 25/09/2013 в 15:24
источник пользователем

голоса
77

Инверсия контроля, (или IoC), о получении свободы (Вы женитесь, вы потеряли свободу , и вы под контролем. Вы разведены, вы только реализованную Инверсию контроля. Это то, что мы называем, «развязаны». Хорошей компьютерной системой отпугивает некоторые очень близкие отношения.) больше гибкости (кухня в вашем офисе служит только чистой водопроводной воды, то есть ваш единственный выбор , если вы хотите пить. Ваш босс реализован Инверсия управления путем создания нового кофеварку. Теперь вы можете гибкость выбора либо водопроводной воды или кофе.) и меньше зависимость (Ваш партнер имеет работу, вы не имеете работу, вы финансово зависит от вашего партнера, так что вы под контролем. Вы найдете работу, вы реализовали Инверсия Контроля. Хорошая компьютерная система поощряет в-зависимости.)

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

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

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

Предположим , что ваш код является группа рабочих. Им нужно , чтобы построить машину. Эти рабочий нужно место и инструменты (фреймворк программного обеспечения) , чтобы построить машину. Традиционные рамки программного обеспечения будут как гараж с большим количеством инструментов. Таким образом, работники должны сделать план себя и использовать инструменты для создания автомобиля. Создание автомобиля не является легким делом, это будет очень трудно для рабочих планировать и правильно сотрудничать. современныйструктура программного обеспечения будет как современный автомобильный завод со всеми удобствами и менеджеров на месте. Рабочие не должны делать какие-либо план, менеджеры (часть структуры, они самые умные люди, и сделал самый сложный план) будет способствовать координации с тем, что рабочие знают, когда делать свою работу (рамочный называет свой код). Рабочие просто должны быть достаточно гибкими, чтобы использовать любые инструменты, менеджеры дают им (с помощью Dependency Injection).

Хотя работники дают контроль управления проектом на высшем уровне в менеджеров (рамки). Но это хорошо, что некоторые специалисты помочь. Это понятие IoC действительно пришел.

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

Dependency Injection и инверсия управления связаны между собой . Dependency Injection находится на микро - уровне и инверсия управления находится на макро - уровне. Вы должны есть каждый укус (реализовать DI), чтобы закончить трапезу (реализации IoC).

Ответил 04/03/2013 в 20:33
источник пользователем

голоса
72

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

Плюсы:

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

Минусы:

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

Лично я вижу сильные стороны IoC, и я действительно люблю их, но я стараюсь, чтобы избежать IoC всякий раз, когда это возможно, потому что это превращает программу в набор классов, которые больше не составляют «реальную» программу, но только то, что нужно положить вместе конфигурации XML или метаданные аннотаций и спадать (и падают) друг от друга и без него.

Ответил 12/02/2010 в 15:31
источник пользователем

голоса
55
  1. Статья Википедии . Для меня, инверсия контроля превращает ваш последовательно написанный код и превратить его в состав делегации. Вместо того, чтобы ваша программа явно контролирующей все, ваша программа создает класс или библиотеку с некоторыми функциями , которые будут вызываться , когда некоторые вещи случаются.

  2. Он решает дублирования кода. Например, в прежние времена вы бы вручную написать свой собственный цикл обработки событий опрашивают системные библиотеки для новых событий. В настоящее время, большинство современного API, вы просто сказать, системные библиотеки, какие события вы заинтересованы, и это даст вам знать, когда они происходят.

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

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

Ответил 06/08/2008 в 05:33
источник пользователем

голоса
38

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

Как и в этом примере с TextEditor: если у вас есть только один SpellChecker может быть, это на самом деле не нужно использовать IoC? Если вам не нужно писать тесты или что-то ...

Так или иначе: быть разумным. Дизайн картина являются хорошими практиками , но не Библия проповедана. Не придерживаться его во всем мире.

Ответил 06/08/2008 в 23:08
источник пользователем

голоса
34

Предположим, вы являетесь объектом. И вы идете в ресторан:

Без IoC : вы просите «яблоко», и вы всегда служили яблоко , когда вы просите больше.

С IoC : Вы можете попросить «фрукты». Вы можете получить различные фрукты каждый раз , когда вы получаете служили. например, яблоко, апельсин, или арбуз.

Таким образом, очевидно, IoC это когда вы любите сорта предпочтительнее.

Ответил 25/09/2013 в 15:00
источник пользователем

голоса
34

IoC / DI мне это выталкивание зависимости для вызывающих объектов. Супер просто.

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

Ответил 19/09/2008 в 03:54
источник пользователем

голоса
23
  1. Инверсия управления является шаблон используется для развязки компонентов и слоев в системе. Паттерн реализуется посредством инжекции зависимостей в компонент, когда она построена. Эта зависимость, как правило, предоставляется в качестве интерфейсов для дальнейшей развязки и поддерживать проверяемость. IoC / DI контейнеры, такие как замок Виндзор, единства инструментов (библиотеки), которые могут быть использованы для обеспечения IoC. Эти инструменты обеспечивают расширенные возможности выше и за рамки простого управления зависимостями, в том числе жизни, АОП / Перехват, политики и т.д.

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

  3. а. Критический при выполнении разработки тестов привода. Без IoC это может быть трудно проверить, так как компоненты тестируемой высоко в сочетании с остальной частью системы.
    б. Критические при разработке модульных систем. Модульная система представляет собой систему, компоненты которой могут быть заменены без необходимости перекомпиляции.
    с. Критические , если есть много сквозных проблем , которые необходимо решать, partilarly в корпоративном приложении.

Ответил 19/09/2008 в 03:27
источник пользователем

голоса
17

Я запишу свое простое понимание этих двух терминов:

For quick understanding just read examples*

Зависимость впрыск (DI):
Зависимость от инъекции обычно означает , передавая объект , от которого зависит метод, в качестве параметра для метода, вместо того , способ создания зависимого объекта .
Что это означает на практике, что метод не зависит непосредственно от конкретной реализации; любая реализация , которая отвечает требованиям , могут быть переданы в качестве параметра.

При этом объекты сказать тир зависимости. И весна делает его доступным.
Это приводит к слабосвязанным разработкам приложений.

Quick Example:EMPLOYEE OBJECT WHEN CREATED,
              IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
   (if address is defines as dependency by Employee object)

Инверсия управления (IoC) контейнера:
Это общая характеристика механизмов МОК управляет объектами Java
- от конкретизации к разрушению через BeanFactory.
-java компоненты, воплощенные в контейнере IoC называются бобы, и контейнер IoC управляет сферу Бина, события жизненного цикла, а также любые возможности АОП , для которых он был настроен и кодированные.

QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it,

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

Инверсия управления в качестве ориентира дизайна преследует следующие цели:

Существует развязка исполнения определенной задачи от реализации.
Каждый модуль может сосредоточиться на том, что он предназначен для.
Модули не делают никаких предположений о том, что делают другие системы , но полагаться на их контракты.
Замена модулей не имеет побочных эффектов на другие модули
Я буду держать вещи абстрактные здесь, Вы можете посетить следующие ссылки для детального понимания темы.
Хорошо читать с примером

Детальное объяснение

Ответил 10/11/2014 в 08:43
источник пользователем

голоса
15

Например, задача # 1 состоит в создании объекта. Без концепции МОК, задача # 1 должна быть сделана Programmer.But с концепцией МОК, задача # 1 будет сделано контейнером.

Короче управление инвертируется от программатора к контейнеру. Таким образом, это называется инверсией контроля.

Я нашел один хороший пример здесь .

Ответил 27/01/2010 в 13:15
источник пользователем

голоса
14

Ответ только первую часть. Что это?

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

Ответил 11/01/2016 в 00:49
источник пользователем

голоса
14

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

Действительно ли нам нужно имя, по которому описать разницу между процедурной и события ориентированного программирования? Хорошо, если нам нужно, но мы должны выбрать совершенно новый «больше, чем жизнь» имя, которое путает больше, чем это решает?

Ответил 19/01/2011 в 04:50
источник пользователем

голоса
13

Пусть сказать, что мы делаем некоторую встречу в каком-нибудь отеле.

Многие люди, многие графины воды, многие пластиковые стаканчики.

Когда кто-то хочет пить, она заполнить чашку, пить и бросить чашку на пол.

Через час или что-то у нас есть пол, покрытый пластиковых стаканчиков и воды.

Пусть контроль инвертировать.

На этом же заседании в том же месте, но вместо пластиковых стаканчиков мы имеем официант с одной стеклянной чашкой (Singleton)

и она все время предлагает гостям пьющих.

Когда кто-то хочет пить, она получить от официанта стекло, пить и вернуть его обратно в официант.

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

И это именно то, что весна (другой контейнер IoC, например: Guice) делает. Вместо того, пусть приложения создать то, что ему необходимо, используя новое ключевое слово (принимая пластиковый стаканчик), Spring IoC контейнер все время предлагают к применению тот же экземпляр (Singleton) от необходимого объекта (стакан воды).

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

Встреча членов потребуется стакан воды, но не кусок пирога.

Пример:-

public class MeetingMember {

    private GlassOfWater glassOfWater;

    ...

    public void setGlassOfWater(GlassOfWater glassOfWater){
        this.glassOfWater = glassOfWater;
    }
    //your glassOfWater object initialized and ready to use...
    //spring IoC  called setGlassOfWater method itself in order to
    //offer to meetingMember glassOfWater instance

}

Полезные ссылки:-

Ответил 26/09/2012 в 18:54
источник пользователем

голоса
13

Я согласен с NilObject , но я хотел бы добавить к этому:

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

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

Ответил 06/08/2008 в 06:20
источник пользователем

голоса
10

IoC о переворачивании отношения между вашим кодом и третья сторона кодой (библиотека / рамкой):

  • В нормальных с / ш развития, вы пишете основной () метод и называют «библиотека» методы. Вы находитесь в контроле :)
  • В IoC «рамка» контролирует основной () и называет свои методы. Framework контролирует :(

DI (Dependency Injection) о том, как проходит контроль в приложении. Традиционное настольное приложение было управление потоком из приложения (метод Main ()) на другие вызовы методов библиотеки, но управление потоком DI инвертируется это основа заботится о запуске вашего приложения, инициализации и активизируют методы по мере необходимости.

В конце концов вы всегда выиграть :)

Ответил 19/09/2014 в 19:25
источник пользователем

голоса
7

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

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

Для тех , кто заинтересован в более подробно на Инверсия управления документ был опубликован с изложением более полную картину Инверсия управления как шаблон проектирования (OfficeFloor: использование офисных шаблонов для улучшения проектирования программного обеспечения http://doi.acm.org/10.1145/ 2739011.2739013 бесплатную копию можно загрузить с http://www.officefloor.net/mission.html )

Что определяется следующая зависимость:

Инверсия управления (для методов) = Dependency (состояние) Инъекции + Продолжение впрыска + Injection Thread

Ответил 29/10/2015 в 04:27
источник пользователем

голоса
7

говоря Программирование

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

Например, допустим , что у нас есть два класса: Dog и Cat . И разделяет то же качество / гласит: возраст, размер, вес. Таким образом , вместо того , чтобы создать класс обслуживания под названием DogService и CatService , я могу создать единый один под названием AnimalService , что позволяет использовать для собак и кошек , только если они используют интерфейс IAnimal .

Тем не менее, прагматично говоря, она имеет некоторые назад.

а) Большинство разработчиков не знает , как использовать его . Например, я могу создать класс под названием Customer и я могу создать автоматически ( с помощью инструментов IDE) интерфейс , который называется ICustomer . Таким образом, это не редкость , чтобы найти папку , наполненные классы и интерфейсы, независимо от того , если интерфейсов будут повторно использовать или нет. Это называется раздутой. Некоторые люди могли бы утверждать , что «может быть в будущем мы могли бы использовать его». : - |

б) имеет некоторые limitings. Например, давайте поговорим о том случае собака и кошка , и я хочу , чтобы добавить новый сервис (функциональность) только для собак. Допустим , что я хочу , чтобы вычислить количество дней , что мне нужно , чтобы обучить собаку ( trainDays()), для кошки это бесполезно, кошки не может быть обучена (я шучу).

стр.1) Если добавить trainDays()к службе AnimalService , то он также работает с кошками , и это не действует вообще.

б2) Я могу добавить условие в trainDays()котором он оценивает , какой класс используется. Но он сломается полностью на IoC.

В.3) можно создать новый класс сервиса под названием DogService только для новой функциональности. Но, это увеличит ремонтопригодность кода , потому что мы будем иметь два класса обслуживания (с аналогичной функциональностью) для собаки , и это плохо.

Ответил 19/04/2015 в 12:07
источник пользователем

голоса
7

Очень простое письменное объяснение можно найти здесь

http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html

он говорит

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

Ответил 22/02/2013 в 15:13
источник пользователем

голоса
6

Мне нравится это объяснение: http://joelabrahamsson.com/inversion-of-control-an-introduction-with-examples-in-net/

Это просто начать и показывает примеры кода, а также.

введите описание изображения здесь

Потребитель, X, необходим потребляемый класс, Y, чтобы сделать что-то. Это все хорошо и естественно, но X действительно нужно знать, что он использует Y?

Разве не достаточно того, что X знает, что он использует то, что имеет поведение, методы, свойства и т.д., из Y, не зная, кто на самом деле реализует поведение?

Извлекая абстрактное определение поведения, используемого X в Y, показанном как я ниже, и позволить потребителю X использовать экземпляр, что вместо Y он может продолжать делать то, что он делает, не зная особенности о Y.

введите описание изображения здесь

В приведенном выше рисунке Y реализует I и X использует экземпляр I. Хотя это вполне возможно, что X все еще использует Y, что интересно, что X не знает, что. Он просто знает, что он использует то, что реализует I.

Читайте статью для получения дополнительной информации и описания преимуществ, таких как:

  • X не зависит от Y больше
  • Более гибкая реализация может быть принято во время выполнения
  • Выделение блока кода, простое тестирование

...

Ответил 16/02/2017 в 02:03
источник пользователем

голоса
4

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

Ответил 24/12/2017 в 18:34
источник пользователем

голоса
4

Я нашел очень яркий пример здесь , который объясняет , как "контроль инвертируется.

Классический код (без Dependency Injection)

Вот как код не используется DI будет примерно работать:

  • Применение потребности Foo (например, контроллер), так:
  • Приложение создает Foo
  • Приложение вызывает Foo
    • Foo Bar необходимо (например, услуги), так:
    • Foo Bar создает
    • Foo вызывает Bar
      • Бар нуждается Бим (сервис, хранилище, ...), так что:
      • Бар создает Бим
      • Бар делает что-то

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

Вот как код с помощью DI будет примерно работать:

  • потребности приложений Foo, который нуждается в баре, который нуждается в Бьет, так:
  • Применение создает Бим
  • Применение создает бар и дает ему Бим
  • Приложение создает Foo и дает ему Bar
  • Приложение вызывает Foo
    • Foo вызывает Bar
      • Бар делает что-то

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

Какие проблемы он решает?

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

Пример: Предположим, что ваше приложение хранит пользователя загруженный файл в Google Drive, с DI ваш контроллер код может выглядеть следующим образом:

class SomeController
{
    private $storage;

    function __construct(StorageServiceInterface $storage)
    {
        $this->storage = $storage;
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

class GoogleDriveService implements StorageServiceInterface
{
    public function authenticate($user) {}
    public function putFile($file) {}
    public function getFile($file) {}
}

Когда ваши требования меняются сказать, вместо GoogleDrive вас просят использовать Dropbox. Вам нужно только написать реализацию идентификации контента для StorageServiceInterface. Вам не нужно вносить никаких изменений в контроллере, пока реализация Dropbox придерживается StorageServiceInterface.

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

Вместо этого , если вы имели класс контроллера построить объект хранения с newключевым словом , как это:

class SomeController
{
    private $storage;

    function __construct()
    {
        $this->storage = new GoogleDriveService();
    }

    public function myFunction () 
    {
        return $this->storage->getFile($fileName);
    }
}

Если вы хотите изменить с реализацией Dropbox вы должны заменить все строки , в которых newобъект GoogleDriveService конструируются и использует DropboxService. Кроме того , при тестировании класса SomeController конструктор всегда ожидает класс GoogleDriveService и фактические методы этого класса срабатывают.

Когда уместно , а когда нет? На мой взгляд , вы используете DI , когда вы думаете , есть (или может быть) альтернативных реализаций класса.

Ответил 04/11/2017 в 13:27
источник пользователем

голоса
4

Я понимаю, что ответ уже дан здесь. Но я до сих пор думаю, некоторые основы о инверсии управления должны обсуждаться здесь в длине для будущих читателей.

Инверсия управления (IoC) был построен на очень простом принципе под названием Голливуд Принцип . И он говорит , что,

Не звоните нам, мы будем называть вас

Что это означает, что не идут в Голливуд, чтобы исполнить свою мечту, а если вы достойны, то Голливуд найти вас и сделать мечта сбывается. Довольно много перевернут, да?

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

В нашем мире программирования, Голливуд представляет собой общие рамки (может быть написано вами или кем -то еще), вы представляете собой код пользователя , который написал и задачи представляют собой вещь , которую вы хотите достичь с вашим кодом. Теперь вы никогда не идут , чтобы вызвать вашу задачу самостоятельно, а не в IoC! Скорее всего вы спроектировали все в таком , что ваша структура будет запускать вашу задачу для вас. Таким образом , вы создали многоразовую структуру , которая может заставить кого - то герой или другие один злодей. Но эта структура всегда отвечает, что не знает , когда выбрать кого - то , и что кто - то знает , что он хочет быть.

Реальный пример жизни будет дан здесь. Предположим, вы хотите создать веб-приложение. Таким образом, вы создаете основу, которая будет обрабатывать все общие вещи, веб-приложение должно обрабатывать как обработку запроса HTTP, создание меню приложений, доступ к страницам, управление куки, запуская события и т.д.

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

Таким образом, идея довольно много просто. Вместо того, чтобы создать пользовательское приложение, которое будет контролировать все сначала создать многоразовую структуру, которая будет контролировать все то писать свои собственные коды и подключить его к каркасу, чтобы выполнить те вовремя.

Laravel и EJB являются примерами таких рамок.

Справка:

https://martinfowler.com/bliki/InversionOfControl.html

https://en.wikipedia.org/wiki/Inversion_of_control

Ответил 01/10/2017 в 11:24
источник пользователем

голоса
4

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

Весна-каркасный referance.pfd страница 27 (если подсчет всех страниц PDF документа, то в 51)

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/pdf/spring-framework-reference.pdf

Ответил 24/01/2013 в 15:52
источник пользователем

голоса
3

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

С точки зрения программирования она прошла функцию обратного вызова getProductList()функции вы выполняетеdoShopping() ;

Это позволяет пользователю функции определить некоторые ее части, что делает его более гибким.

Ответил 15/12/2017 в 18:35
источник пользователем

голоса
3

Для понимания концепции, Инверсия управления (IoC) или Принцип инверсии зависимостей (DIP) включает в себя два вида деятельности: абстракции и инверсии. Dependency Injection (DI) является лишь одним из немногих методов инверсии.

Чтобы узнать больше об этом вы можете прочитать мой блог здесь

  1. Что это?

Это практика, где вы позволяете реальное поведение извне границы (класс в объектно-ориентированном программировании). Границу сущность знает только абстракции (например, интерфейс, абстрактный класс, делегат в объектно-ориентированном программировании) от него.

  1. Какие проблемы он решает?

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

  1. Когда уместно, а когда нет?

Уместно большая часть времени, если у вас есть ситуации, когда вы просто хотите монолитный код (например, очень простая программа)

Ответил 03/06/2016 в 01:46
источник пользователем

голоса
3

Создание объекта внутри класса называется тесная связь, весна удаляет эту зависимость, следуя шаблон проектирования (DI / МОК). В какой объект класса в принятый в конструкторе, а не создавать в классе. Более того мы даем супер ссылочный класс переменной в конструкторе, чтобы определить более общую структуру.

Ответил 13/05/2015 в 08:52
источник пользователем

голоса
3
  1. Таким образом число 1 выше . Что такое инверсия управления?

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

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

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

public class MessagePublisher<RECORD,MESSAGE>
{
    public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
    {
      //setup
    }
}

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

Ах да, есть проблемы тестируемости, но они являются вторичными по отношению к преимуществам IoC / DI.

Я определенно любящий IoC / DI.

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

Ответил 19/09/2008 в 05:59
источник пользователем

голоса
2

Использование IoC вы не new'ing своих объектов. Ваш контейнер IoC будет делать и управлять временем жизни их.

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

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

Ответил 16/07/2015 в 16:06
источник пользователем

голоса
1

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

Ответил 03/04/2017 в 22:42
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more