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


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

  1. Что это?
  2. Какие проблемы он решает?
  3. Когда это уместно, а когда нет?

1401


источник


Ответы:


Образцы инверсии управления (IoC) и зависимостей (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подпись.

Это просто простой пример: хорошая серия статей Симона Бусоли, которая объясняет это более подробно.


1114



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

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

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

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

В программе GUI или что-то вроде этого, вместо этого мы говорим

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

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

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


489



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

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

  1. отдельный какие -делать часть из когда -то-часть.
  2. Гарантировать, что когда часть, известная как немного насколько возможно какие часть; и наоборот.

Для каждого из этих шагов существует несколько способов, основанных на технологии / языке, которые вы используете для своей реализации.

-

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

-

Примеры

  • Обработка событий. Обработчики событий (часть, посвященная действию) - Подъем событий (часть, выполняемая отдельно)
  • Интерфейсы. Компонентный клиент (часть, выполняемая отдельно) - реализация интерфейса компонента (часть, выполняемая)
  • xUnit fixure. Setup и TearDown (часть для чего-то) - фреймворки xUnit обращаются к Setup в начале и TearDown в конце (часть, выполняемая отдельно)
  • Шаблон дизайна шаблона. метод шаблона in-do part - примитивный подкласс реализация какая-то часть
  • DLL-контейнеры в COM. DllMain, DllCanUnload и т. Д. (Часть, предназначенная для работы) - COM / OS (часть, выполняемая по отдельности)

357



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

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

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

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


83



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

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

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

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

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

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

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

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


78



Before using Inversion of Control you should be well aware of the fact that it has its pros and cons and you should know why you use it if you do so.

Pros:

  • Your code gets decoupled so you can easily exchange implementations of an interface with alternative implementations
  • It is a strong motivator for coding against interfaces instead of implementations
  • It's very easy to write unit tests for your code because it depends on nothing else than the objects it accepts in its constructor/setters and you can easily initialize them with the right objects in isolation.

Cons:

  • IoC not only inverts the control flow in your program, it also clouds it considerably. This means you can no longer just read your code and jump from one place to another because the connections that would normally be in your code are not in the code anymore. Instead it is in XML configuration files or annotations and in the code of your IoC container that interprets these metadata.
  • There arises a new class of bugs where you get your XML config or your annotations wrong and you can spend a lot of time finding out why your IoC container injects a null reference into one of your objects under certain conditions.

Personally I see the strong points of IoC and I really like them but I tend to avoid IoC whenever possible because it turns your software into a collection of classes that no longer constitute a "real" program but just something that needs to be put together by XML configuration or annotation metadata and would fall (and falls) apart without it.


72



  1. Wikipedia Article. To me, inversion of control is turning your sequentially written code and turning it into an delegation structure. Instead of your program explicitly controlling everything, your program sets up a class or library with certain functions to be called when certain things happen.

  2. It solves code duplication. For example, in the old days you would manually write your own event loop, polling the system libraries for new events. Nowadays, most modern APIs you simply tell the system libraries what events you're interested in, and it will let you know when they happen.

  3. Inversion of control is a practical way to reduce code duplication, and if you find yourself copying an entire method and only changing a small piece of the code, you can consider tackling it with inversion of control. Inversion of control is made easy in many languages through the concept of delegates, interfaces, or even raw function pointers.

    It is not appropriate to use in all cases, because the flow of a program can be harder to follow when written this way. It's a useful way to design methods when writing a library that will be reused, but it should be used sparingly in the core of your own program unless it really solves a code duplication problem.


55



But I think you have to be very careful with it. If you will overuse this pattern, you will make very complicated design and even more complicated code.

Like in this example with TextEditor: if you have only one SpellChecker maybe it is not really necessary to use IoC ? Unless you need to write unit tests or something ...

Anyway: be reasonable. Design pattern are good practices but not Bible to be preached. Do not stick it everywhere.


38



Suppose you are an object. And you go to a restaurant:

Without IoC: you ask for "apple", and you are always served apple when you ask more.

With IoC: You can ask for "fruit". You can get different fruits each time you get served. for example, apple, orange, or water melon.

So, obviously, IoC is preferred when you like the varieties.


35



IoC / DI to me is pushing out dependencies to the calling objects. Super simple.

The non-techy answer is being able to swap out an engine in a car right before you turn it on. If everything hooks up right (the interface), you are good.


34



  1. Inversion of control is a pattern used for decoupling components and layers in the system. The pattern is implemented through injecting dependencies into a component when it is constructed. These dependences are usually provided as interfaces for further decoupling and to support testability. IoC / DI containers such as Castle Windsor, Unity are tools (libraries) which can be used for providing IoC. These tools provide extended features above and beyond simple dependency management, including lifetime, AOP / Interception, policy, etc.

  2. a. Alleviates a component from being responsible for managing it's dependencies.
    b. Provides the ability to swap dependency implementations in different environments.
    c. Allows a component be tested through mocking of dependencies.
    d. Provides a mechanism for sharing resources throughout an application.

  3. a. Critical when doing test-driven development. Without IoC it can be difficult to test, because the components under test are highly coupled to the rest of the system.
    b. Critical when developing modular systems. A modular system is a system whose components can be replaced without requiring recompilation.
    c. Critical if there are many cross-cutting concerns which need to addressed, partilarly in an enterprise application.


23



I shall write down my simple understanding of this two terms:

For quick understanding just read examples*

Dependency Injection(DI):
Dependency injection generally means passing an object on which method depends, as a parameter to a method, rather than having the method create the dependent object.
What it means in practice is that the method does not depends directly on a particular implementation; any implementation that meets the requirements can be passed as a parameter.

With this objects tell thier dependencies. And spring makes it available.
This leads to loosely coupled application development.

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

Inversion of Control(IoC) Container:
This is common characteristic of frameworks, IOC manages java objects
– from instantiation to destruction through its BeanFactory.
-Java components that are instantiated by the IoC container are called beans, and the IoC container manages a bean's scope, lifecycle events, and any AOP features for which it has been configured and coded.

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.

By implementing Inversion of Control, a software/object consumer get more controls/options over the software/objects, instead of being controlled or having less options.

Inversion of control as a design guideline serves the following purposes:

There is a decoupling of the execution of a certain task from implementation.
Every module can focus on what it is designed for.
Modules make no assumptions about what other systems do but rely on their contracts.
Replacing modules has no side effect on other modules
I will keep things abstract here, You can visit following links for detail understanding of the topic.
A good read with example

Detailed explanation


17