주말 에세이. - IOC와 DI에 대해서 얘기를 나눠보도록 하겠습니다.

먼저 본고는 어떻게 시스템의 확장성을 높여 교체 원가를 낮출 수 있는지 연구하고자 한다.개발 속도를 추구하는 것은 전혀 아랑곳할 필요가 없다.
IoC 제어 반전
IoC(Inverse of Control)는 반전을 제어한다. 그러나 이 표현은 직설적이지 않아 실제 생산에서 제어 이동으로 묘사하는 것이 오히려 옳다.오늘은 글자를 따지지 않고 대상의 통제권을 제3자에게 넘긴다. 흔히 어떤 인터페이스가 구체적으로 클래스의 선택 통제권을 호출 클래스에서 제거하고 제3자에게 결정한다.그래도 이해가 안돼.
DI 의존 주입
이후 Martin Fowler는 IoC를 대체하기 위해 DI(Dependency Injection) 의존 주입이라는 개념을 제시했다. 즉,
호출류가 특정한 인터페이스 실현류에 대한 의존 관계를 제3자(용기 또는 협동류)에 주입하여 호출류가 특정한 인터페이스 실현류에 대한 의존을 제거한다.
의존 주입은 분명히 반전을 통제하는 것보다 더 잘 이해된다.
하나의 예를 보다

interface I {
    void foo();

class A implements I{
    public A() {
        //...
    }
    //...
}

class B {
    I i;
    public B() {
        i = new A();
        //...
    }
    public void bar() {
    }
}

이를 통해 알 수 있듯이 클래스 B의 기능은 A에 의존하고 여기에 조합을 사용했다.물론 조합을 사용하는 것이 B에게 A를 계승하고 확장하는 것보다 훨씬 낫다. 이것은 오늘 논의할 것이 아니다.이 예의 문제는 B가 의존하는 A는 B가 구축한다는 것이다.보아하니 별 문제가 없는 것 같지만:

B는 A의 창설을 책임지고 SRP 단일 직책 원칙에 부합되지 않는다.

A 업무가 확장될 때 구조 함수에 변화가 발생할 수 있으므로 B의 구조 함수를 수정해야 하며 OCP 개폐원칙에 부합되지 않는다

인터페이스를 향해 프로그래밍을 하지 않으면 이 코드는 더욱 나빠질 것이다. 뒤의 편의를 위해 인터페이스 I(본문의 주의력 분산을 줄이기 위해)를 제시했다

만약에 업무가 발전할 때 B가 자류가 필요할 때 재구성일 가능성이 크다(리씨대환원칙에 부합되지 않을 가능성이 높기 때문에 더 이상 토론하지 않겠다).

이것이 바로 모두가 말한 결합이 높아졌다는 것이다.
IoC나 DI에 따라 코드를 구축하면 이런 문제를 줄일 수 있다.
주입 방식에 의존하다

구조 함수 주입

setter 방법 주입

인터페이스 주입

주석 주입

구조 함수 주입

class B {
    I i;
    public B(I i) {
        this.i = i;
    }
}

이렇게 선택 제어권은 더 이상 B(IoC가 묘사하고자 하는)에 속하지 않고 주입 형식으로 의존 대상의 획득을 실현했다(DI가 묘사하고자 하는).
setter 메소드 주입

class B {
    I i;
    public B() {
    }

    public void setI(I i) {
        this.i = i;
    }
}

인터페이스 주입
정의 주입 인터페이스: 위 인터페이스 이름이 잘 정해지지 않아서 잠시 수정하지 않겠습니다

interface InjectDependencyI {
    void setI(I i);
}

class B implements InjectDependencyI {
    I i;
    public B() {
    }

    public void setI(I i) {
        this.i = i;
    }
}

setter 주입과는 차이가 크지 않지만 인터페이스 I의 고객이 여러 명이고 계승 관계나 형제 관계가 없을 때 인터페이스 주입을 사용하면 효과가 좋고 코드 전체의 가독성이 좋다.
주해 주입
분명히 여기에 IoC 용기가 존재하는데 규칙에 따라 일정한 자동화 처리를 도와 수동으로 주입하는 작업을 줄이고 이런 규칙들은 주석으로 기술한 것이다.
Android에서 Dagger/Dagger를 많이 사용합니다. 2.이 편은 우선 확장하지 않겠다.
맨 마지막에 쓰다
왜 안드로이드 클라이언트 업무에서 우리는 IoC/DI의 역할을 비교적 체득하기 어렵습니까?
흔히 실제 상황은 인터페이스, 상호작용에 더 많은 주의력을 기울이고 업무 부분이 그렇게 방대하지 않다. 어떤 업무의 고객은 하나일 수 있다. 비록 현재의 디자인 결합이 높아서 확장에 불리하지만 모순이 폭발할 기회가 전혀 없다.