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 기반 시스템에서 프레임 워크는 버튼, 메뉴, 창 및 대화 상자와 같은 UI 요소를 만드는 데 이미 사용할 수 있습니다. 내 애플리케이션의 비즈니스 로직을 작성할 때, 내 비즈니스 로직 코드 (이벤트가 시작될 때)를 호출하는 것은 프레임 워크의 이벤트가되고 그 반대가 아닙니다.
프레임 워크의 코드는 내 비즈니스 로직을 인식하지 못하지만 여전히 내 코드를 호출하는 방법을 알고 있습니다. 이는 이벤트 / 대리자, 콜백 등을 사용하여 수행됩니다. 여기서 흐름 제어는 "반전"됩니다.
따라서 정적으로 바인딩 된 개체의 제어 흐름에 의존하는 대신 흐름은 전체 개체 그래프와 서로 다른 개체 간의 관계에 따라 달라집니다.
의존성 주입은 객체의 의존성을 해결하기위한 IoC 원칙을 구현하는 디자인 패턴입니다.
간단히 말해서 코드를 작성하려고 할 때 다른 클래스를 만들고 사용하게됩니다. 한 클래스 (클래스 A)는 다른 클래스 (클래스 B 및 / 또는 D)를 사용할 수 있습니다. 따라서 클래스 B와 D는 클래스 A의 종속성입니다.
간단한 비유는 Car 클래스입니다. 자동차는 엔진, 타이어 등과 같은 다른 클래스에 의존 할 수 있습니다.
종속성 주입은 종속성 (Class Engine 및 클래스 Tyre)을 만드는 Dependent 클래스 (여기서는 Class Car) 대신 종속성의 구체적인 인스턴스와 함께 클래스를 주입해야합니다.
보다 실용적인 예를 들어 이해하겠습니다. 자신 만의 텍스트 편집기를 작성하고 있다고 생각해보십시오. 무엇보다도 사용자에게 텍스트의 오타를 검사하는 기능을 제공하는 맞춤법 검사기를 사용할 수 있습니다. 이러한 코드의 간단한 구현은 다음과 같습니다.
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 함수를 호출하고 사용자에게 표시 할 오타 목록을 찾습니다.
한 사용자가 편집기에서 프랑스어를 쓰기 시작하는 어느 화창한 날까지 모든 것이 잘 작동하는 것 같습니다.
더 많은 언어에 대한 지원을 제공하려면 더 많은 SpellChecker가 필요합니다. 아마도 프랑스어, 독일어, 스페인어 등일 것입니다.
여기에서 우리는 TextEditor 클래스와 밀접하게 결합 된 "English"SpellChecker를 사용하여 밀접하게 결합 된 코드를 만들었습니다. 이는 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 인스턴스에 삽입 할 수 있습니다.
여기 에서 전체 기사를 읽을 수 있습니다.