반전 제어 (IoC) 및 의존 주입 (DI)

출처: 반전 제어 (IoC) 및 의존 주입 (DI)

반전을 제어하는 것은 무엇입니까

제어 반전을 토론하기 전에 소프트웨어 시스템의 결합 대상을 살펴보자.
![Upload 캡처.PNG failed. Please try again.]그림에서 볼 수 있듯이 소프트웨어의 대상은 톱니바퀴처럼 협동하여 일을 하지만 서로 결합하여 부품 하나가 정상적으로 작동하지 못하면 전체 시스템이 붕괴된다.이것은 강한 결합 시스템이다.톱니바퀴 그룹에서 톱니바퀴 간의 맞물림 관계는 소프트웨어 시스템의 대상 간의 결합 관계와 매우 비슷하다.대상 간의 결합 관계는 피할 수 없을 뿐만 아니라 필요한 것이다. 이것은 협동 작업의 기초이다.현재 공업급 응용의 규모가 점점 커지고 대상 간의 의존 관계도 점점 복잡해지면서 대상 간의 다중 의존 관계가 자주 나타나기 때문에 구조자와 디자이너는 시스템에 대한 분석과 디자인에 더욱 큰 도전에 직면하게 될 것이다.대상 간의 결합도가 지나치게 높은 시스템은 반드시 한 발을 끌고 온몸을 움직이는 상황이 나타날 것이다.소프트웨어 전문가인 Michael Mattson은 객체 간 결합이 지나치게 높은 문제를 해결하기 위해 객체 간'디커플링'을 달성하기 위한 IOC 이론을 제시했다.반전 제어(Inversion of Control)는 컴퓨터 코드 간의 결합도를 낮추기 위한 대상 프로그래밍의 설계 원칙이다.그 기본 사상은'제3자'를 빌려 의존 관계를 가진 대상 간의 결합을 실현하는 것이다.
![Upload image.png failed. Please try again.] 중간 위치의'제3자', 즉 IOC 용기를 도입했기 때문에 A, B, C, D 네 개의 대상은 결합 관계가 없어졌고 톱니바퀴 간의 전동은 모두'제3자'에 의존했다. 모든 대상의 통제권은'제3자'IOC 용기에 상납되었다. 그래서 IOC 용기는 전체 시스템의 관건적인 핵심이 되었고 이것은'접착제'와 유사한 역할을 했다.시스템에 있는 모든 대상을 한데 붙여 역할을 하는데, 이'접착제'가 없으면 대상과 대상 사이에 서로 연결고리가 끊어질 수 있다는 것이 IOC 용기를'접착제'에 비유하는 이유다.반전 제어(IOC)는 도대체 왜 이런 이름을 지었는지 다시 한 번 살펴봅시다.우리 비교해 보자.

1. 소프트웨어 시스템이 IOC 용기를 도입하기 전에 그림1에서 보듯이 대상 A는 대상 B에 의존한다. 그러면 대상 A는 초기화하거나 특정한 지점으로 실행할 때 자신이 주동적으로 대상 B를 만들거나 이미 만든 대상 B를 사용해야 한다.객체 B를 작성하든 사용하든 제어권은 자신에게 있습니다.

2. 소프트웨어 시스템은 IOC 용기를 도입한 후에 이런 상황이 완전히 바뀌었다. 그림2에서 보듯이 IOC 용기의 가입으로 대상 A와 대상 B 사이에 직접적인 관계가 없기 때문에 대상 A가 필요 대상 B로 운행될 때 IOC 용기는 주동적으로 대상 B를 만들어 대상 A가 필요로 하는 곳에 주입한다.

앞뒤의 대비를 통해 우리는 대상 A가 의존 대상 B를 얻는 과정이 주동적인 행위에서 수동적인 행위로 바뀌고 통제권이 뒤바뀌었다는 것을 알 수 없다. 이것이 바로'통제반전'이라는 명칭의 유래이다.반전을 통제하는 것은 소프트웨어 공학의 이론이 아니라 생활 속에서도 이런 사상이 유용하다.다시 한 번 현실 생활의 예를 들자면 하이얼회사는 전기 제조업체로서 자신의 상품을 전국 각지에 판매해야 한다. 그러나 서로 다른 판매 경로에 서로 다른 게임 방법이 있다는 것을 발견하고 각종 판매 대표를 파견하여 서로 다른 게임을 한다. 채널이 갈수록 많아지면서 채널이 증가할 때마다 한 무리의 사람과 새로운 절차를 추가하고 각 채널 업체의 게임 방법에 심각하게 결합시킨다.정말 견딜 수 없어서 업무 기준을 제정하고 판매 정보화 시스템을 개발하는데 이 기준에 부합되는 채널 업체만이 하이얼의 판매 업체가 될 수 있다.각 채널 업체로 하여금 자신의 표준에 거꾸로 의존하게 하다.제어를 반전시키고 의존을 거꾸로 하다.우리는 하이얼과 판매상을 소프트웨어 대상으로 하고 정보화 시스템을 IOC 용기로 판매한다. IOC 용기가 없기 전에 판매상은 그림1의 톱니바퀴처럼 톱니바퀴를 하나 늘리면 다른 톱니바퀴에 의존하는 여러 가지를 늘려야 하기 때문에 시스템이 갈수록 복잡해지는 것을 알 수 있다.세일즈 시스템을 개발한 후 모든 세일즈맨은 세일즈 시스템에만 의존하고 그림2에 나타난 것처럼 톱니바퀴를 쉽게 추가하고 삭제할 수 있다.

의존 주입

의존 주입은 인스턴스 변수를 개체로 전달합니다(Dependency injection means giving an object its instance variables).

의존성

만약에 Class A에 Class B의 실례가 있다면 Class A는 Class B에 대한 의존도가 있다고 한다.예를 들어 다음 클래스Human에서Father 대상을 사용하면 클래스Human은 클래스Father에 의존한다고 할 수 있다.

public class Human {
    ...
    Father father;
    ...
    public Human() {
        father = new Father();
    }
}

이 코드를 자세히 보면 우리는 몇 가지 문제가 존재하는 것을 발견할 수 있다.

1. 지금father 생성 방식을 바꾸려면 newfather(String name)로father를 초기화하려면Human 코드를 수정해야 한다.

2. 서로 다른father 대상이 Human에 미치는 영향을 테스트하려면 매우 어렵다. 왜냐하면father의 초기화는 Human의 구조 함수에 쓰여 있기 때문이다.

3. 만약 new Father() 과정이 매우 느리다면 단일 측정 시 우리는 이미 초기화된 father 대상 Mock으로 이 과정을 제거하기를 희망하는 것도 매우 어렵다.

의존 주입

위에서 구조 함수에 의존하여 직접 초기화하는 것은 두 종류가 독립적이지 않아 테스트하기 불편하다는 단점이 있는 하드 init 방식이다.다음과 같은 다른 Init 방법이 있습니다.

public class Human {
    ...
    Father father;
    ...
    public Human(Father father) {
        this.father = father;
    }
}

위 코드에서, 우리는father 대상을 구조 함수의 매개 변수로 전송할 것이다.Human의 구성 방법을 사용하기 전에 외부에서Father 객체가 초기화되었습니다.이처럼 스스로 의존을 초기화하지 않고 외부를 통해 의존을 전달하는 방식을 의존 주입이라고 한다.현재 우리는 상기 1에 존재하는 두 가지 문제가 모두 잘 해결되었다는 것을 발견했다. 쉽게 말하면 의존 주입은 주로 두 가지 장점이 있다.