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의 종속성입니다.
간단한 비유는 클래스 카가 될 것입니다. 자동차는 엔진, 타이어 등과 같은 다른 클래스에 의존 할 수 있습니다.
의존성 주입은 의존성 (클래스 엔진 및 클래스 타이어)을 생성하는 의존성 클래스 (클래스 카) 대신 클래스가 의존성의 구체적인 인스턴스로 주입되어야한다고 제안합니다.
보다 실제적인 예를 통해 이해할 수 있습니다. 자신 만의 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 함수를 호출하고 사용자에게 표시 할 오타 목록을 찾습니다.
한 명의 사용자가 편집자에서 프랑스어를 쓰기 시작하는 좋은 날까지 모든 것이 잘 작동하는 것 같습니다.
더 많은 언어를 지원하려면 더 많은 SpellChecker가 있어야합니다. 아마도 프랑스어, 독일어, 스페인어 등
여기서는 "English"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 인스턴스에 삽입 할 수 있습니다.
여기 에서 전체 기사를 읽을 수 있습니다
