Инверсия управления - это общий принцип построения архитектуры программного обеспечения, который помогает в создании многократно используемых модульных программных сред, которые легко поддерживать.
Это принцип проектирования, в котором поток управления «принимается» из библиотеки, написанной в общих чертах, или повторно используемого кода.
Чтобы лучше понять это, давайте посмотрим, как мы кодировали в первые дни кодирования. В процедурных / традиционных языках бизнес-логика обычно управляет потоком приложения и «вызывает» общий или повторно используемый код / функции. Например, в простом консольном приложении мой поток управления управляется инструкциями моей программы, которые могут включать вызовы некоторых общих функций многократного использования.
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, Frameworks - это повторно используемый код, который «вызывает» бизнес-логику.
Например, в системе на основе 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 DI. Измененный класс TextEditor будет выглядеть примерно так:
Class TextEditor
{
ISpellChecker objSpellChecker;
string Text;
public void TextEditor(ISpellChecker objSC)
{
objSpellChecker = objSC;
}
public ArrayList <typos> CheckSpellings()
{
return objSpellChecker.CheckSpelling();
}
}
Таким образом, вызывающий код при создании текстового редактора может внедрить соответствующий тип SpellChecker в экземпляр TextEditor.
Вы можете прочитать полную статью здесь