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

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

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

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

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

В программе GUI или somesuch, вместо этого мы говорим:

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

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

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

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

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

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

МОК / DI мне выставляет зависимости к вызывающим объектам. Супер простой.

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

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

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

, Если Вы копируете и вставить код вокруг, Вы почти всегда делаете что-то неправильно. Шифруемый как принцип разработки Однажды и Только Однажды .

1. Инверсия управления является шаблоном, используемым для разъединения компонентов и слоев в системе. Шаблон реализован посредством введения зависимостей в компонент, когда это создается. Эти зависимости обычно обеспечиваются как интерфейсы для дальнейшего разъединения и поддерживать тестируемость. МОК / контейнеры DI, такие как замок Windsor, Единица является инструментами (библиотеки), которыми можно пользоваться для обеспечения МОК. Эти инструменты обеспечивают расширенные функции выше и вне простого управления зависимостью, включая время жизни, AOP / Перехват, политика, и т.д.

2. a. Облегчает компонент от того, чтобы быть ответственным за управление, это - зависимости.
   b. Обеспечивает способность подкачать реализации зависимости в различных средах.
   c. Позволяет компоненту быть протестированным посредством насмешки зависимостей.
   d. Обеспечивает механизм для совместного использования ресурсов всюду по приложению.

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

1. Так номер 1 выше . , Что такое Инверсия Управления?

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

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

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

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

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

, О, да, существуют проблемы тестируемости, но они вторичны к преимуществам МОК/DI.

я определенно люблю МОК/DI.

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

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

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

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

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

я прочитал много ответов для этого, но если кто-то все еще смущен и нуждается плюс крайний "laymans в термине", чтобы объяснить, что МОК вот является моим взятием:

Воображают родителя и ребенка, говорящего друг с другом.

Без МОК:

*Parent: можно только говорить, когда я задаю Вам вопросы, и можно только действовать, когда я даю Вам разрешение.

Родитель : Это означает, Вы не можете спросить меня, если можно поесть, играть, перейдите к ванной или даже спите, если я не спрашиваю Вас.

Родитель : Вы хотите поесть?

Ребенок : Нет.

Родитель : Хорошо, я вернусь. Ожидайте меня.

Ребенок : (Хочет играть, но так как нет никакого вопроса от родителя, ребенок ничего не может сделать).

После 1 часа...

Родитель : я вернулся. Вы хотите играть?

Ребенок : Да.

Родитель : Разрешение дано.

Ребенок : (наконец удается играть).

Этот простой сценарий объясняет, что управление центрируется к родителю. Свобода ребенка ограничивается и высоко зависит от вопроса родителя. Ребенок может ТОЛЬКО [1 132] говорить при выяснении говорить, и может ТОЛЬКО [1 133] действие когда данное разрешение.