[Android Dagger2] 의존성 주입의 필요성(DI)

안녕하세요 헬창코딩입니다.

 

예전에 dagger2를 간단하게 사용해봤었는데요.

이번에는 의존성 주입이 왜 필요한지 자세하게 알아보도록 하겠습니다. 

 

사실 처음 dagger2를 사용해보면 느끼겠지만 오히려 안 쓰는 게 더 편한 거 같은데;; 왜 사용하는 거지??라는

의문점이 드실 겁니다.

 

저도 그랬습니다.

 

사실 간단한 프로젝트에는 사용을 안 하는 것이 더 좋을 것 같습니다. 

 

하지만 프로젝트가 커질수록 디자인 패턴의 중요성, 그리고 그 안에서 사용되는 dagger2의 필요성을 느끼실 수 있을 겁니다.

 

그럼 필요성을 자세하게 알아보도록 하겠습니다. 

 

 

1. 변경의 전이

예를 들어서 한번 보겠습니다. 

public class Computer {

    public A_CPU cpu; //변경됨

    public Computer() {
        cpu = new A_CPU(); //변경됨
    }

}

위에 코드에서 보면 'Computer'는 'CPU'라는 한 가지 타입에 의존합니다. 하지만 사용자는 다른 타입의 CPU를 사용하는 것을 원할 수도 있습니다. 예를 들어 A사의 CPU로 조립하기를 원한다면 CPU 클래스명을 A_CPU로 변경하거나 새로 만들어야 합니다.

하나의 클래스를 변경하거나 새로 만드는 것은 어렵지 않습니다.

하지만 여기서 문제점은 CPU클래스를 의존하던 Computer 클래스도 같이 변경해야 한다는 점입니다.

--> 즉 하나의 클래스를 변경함으로써 다른 의존관계까지 변경사항이 전이가 됩니다. 

 

이 문제를 해결할 방법은 Computer가 의존하는 CPU를 interface로 만드는 것입니다. CPU를 구현 어떤 클래스 간에 Computer의 CPU로 기능할 수 있습니다. 

public interface CPU {...}

public class A_CPU implements CPU{...}

public class Computer {

    public CPU cpu;
    public Computer() {
        cpu = new A_CPU();
        //cpu = new N_CPU();
    }
}

하지만 여전히 문제는 남아있습니다. CPU를 인터페이스로 변경함에 따라 변경의 전이를 최소화했지만, Computer클래스에서 CPU 객체를 생성하고 관리해 N회사의 CPU를 사용한다면 또다시 Computer 클래스를 변경해야 합니다.

 

 

2. 제어의 역전

제어의 역전은 어떠한 일을 수행하도록 만들어진 프레임워크에 제어권을 위임함으로써 관심사를 분리하는 것을 의미합니다.

제어의 역전을 통해 앞의 코드들의 문제점을 해결해 볼 수 있습니다. 

public class Computer {

    public CPU cpu;

    public Computer() {
    }

    public Computer(CPU cpu) {
        this.cpu = cpu;
    }

    public void setCpu(CPU cpu) {
        this.cpu = cpu;
    }
}

public static void main(String args){
    CPU cpu = new I_Cpu;
    Computer computer1 = new Computer(cpu);
    //혹은
    Computer computer2 = new Computer();
    computer2.setCpu(cpu);
}

Computer 클래스의 생성자에서 CPU 객체를 만들지 않고 외부로부터 CPU객체를 생성한 뒤

Computer 생성자 또는 메서드의 매개 변수로 객체를 제공합니다.

 

기존에는 Computer가 CPU의 객체를 생성하고 관리했으나 개선된 코드에는 CPU 객체의 생성 및 관리를 외부에 위임했습니다.

이를  제어의 역전이라고 합니다.

 

제어의 역전을 통해 결합도를 약하게 만들었고, Computer는 이제 CPU의 변경 사항에 내부 필드나 메서드 매개변수를 변경하지 않아도 됩니다. 

 

지금까지 의존성 주입의 필요성을 알아봤는데요~

 

다음의 의존성 주입의 장단점을 알아보도록 하겠습니다. 

 

의존성주입의 장점

1. 의존성 주입은 인터페이스를 기반으로 설계되며, 코드를 유연하게 합니다.

2. 주입하는 코드만 따로 변경하기 쉬워 리펙토링이 수월합니다.

3. 의존성 주입을 사용하는 결과로 stub나 mock 객체를 사용하여 단위 테스트를 하기가 쉬워집니다. (가장 큰 장점)

4. 클래스 간의 결합도를 느슨하게 합니다.

5. 인터페이스를 기반으로 설계하므로 여러 개 발자가 서로 사용하는 클래스를 독립적으로 개발할 수 있습니다. (즉 클래스 간에 의존하는 인터페이스만 알면 됩니다. )

 

 

의존성 주입의 단점

1. 간단한 프로그램을 만들 때는 번거롭습니다.

2. 의존성 주입은 동작과 구성을 분리해 코드를 추적하기 어렵게 하고 가독성을 떨어뜨릴 수 있습니다.

(개발자는 더 많은 파일을 참조해야 합니다.)

3. Dagger2와 같은 의존성 주입 프레임워크는 컴파일 타임에 애노테이션 프로세서를 이용하여 파일을 생성하므로 

빌드 시간이 조금 더 소요됩니다. 

 

 

결론

짧은 기간 개발하고, 더는 유지 보수를 안하는 간단한 프로그램을 만드는 경우에는 의존성주입의 사용을 추천하지 않습니다. 왜냐하면 의존성 주입을 하려고 인터페이스 기반으로 설계하고, 의존성 주입 프레임워크의 설정 등이 생산성을 떨어뜨리기 때문입니다.

 

하지만 일반적인 사용 애플리케이션을 만들고, 지속해서 유지 보수를 할 경우에는 오히려 생산성을 향상시킵니다.