모바일에서의 Dependency Injection - Part1.

들어가며

모바일 앱개발에서도 아키텍처가 고도화 되면서 DI 사용은 필수적인 요소가 되어가고 있습니다. 저희 프롬 모바일팀도 android, ios 개발 시 DI를 적극적으로 활용하고 있으며 다양한 DI툴을 통해 보다 쉽게 DI를 적용하고 있습니다. 이번 포스트에서는 DI에 대한 개념과 구현을 간단한 예제를 통해 알아보고자 합니다. 또 dagger라는 di framework을 사용하면서 DI에 대해서 조금 더 깊은 이해를 돕고자합니다.

Dependency Injection(DI) 이란?

DI는 Dependency Injection, 의존성 주입의 약자 입니다. 위키백과에는 “프로그래밍에서 구성요소간의 의존 관계가 소스코드 내부가 아닌 외부의 설정파일 등을 통해 정의되게 하는 디자인 패턴 중의 하나이다.” 라고 정의되어 있습니다. DI를 활용하면 클래스 레벨에서 의존관계가 고정되지 않도록 하고 동적으로 의존성을 주입해주면서 코드의 유연성을 확보하고 결합도를 낮출 수 있게 됩니다. 간단한 예제 코드를 만들면서 어떤 말인지 이해해보도록 하겠습니다.

이번 포스트의 예제 코드는 Java로 진행하겠습니다. (각 모바일 플랫폼에서의 DI적용 관련해서도 포스팅 진행할 예정인데 이때는 kotlin, swift 예제로 진행할 예정입니다. 이번 포스트는 dagger를 통해 DI에 대해서 알아볼 예정이라 dagger가 구성된 언어인 java로 예제를 구성하였습니다.)

예제는 Dagger 에서도 사용하고 있는 Coffee Maker 예제를 사용하겠습니다. 먼저 DI 없이 Coffee Maker 에서 커피를 내려보겠습니다. Coffee를 내리는데는 열을 가하는 Heater 와 압력을 가하는 pump 가 필요합니다. Heater 는 on / off 와 뜨거운지를 확인하는 기능(isHot)이 있고 pump는 pump 하는 기능이 있습니다. 인터페이스를 구현해봅시다.

public interface Heater { void on(); void off(); boolean isHot(); }
public interface Pump { void pump(); }

그리고 Heater 와 Pump 를 사용해 커피를 내려주는 Coffee Maker 클래스를 구현해봅시다.

public class CoffeeMaker { 
    private final Heater heater; 
    private final Pump pump; 
    
    public CoffeeMaker(Heater heater, Pump pump) { 
        this.heater = heater; this.pump = pump; 
    } 
    
    public void brew(){ 
        heater.on(); 
        pump.pump(); 
        System.out.println(" [_]P coffee! [_]P "); 
        heater.off(); 
    } 
}

이제 A_Heater 와 A_Pump 라는 인터페이스 구현체를 구현해보겠습니다.

public class A_Heater implements Heater { 
    boolean heating; 
    
    public void on() { 
        System.out.println("A_Heater : ~ ~ ~ heating ~ ~ ~"); 
        this.heating = true; 
    }
    
    public void off() { 
        this.heating = false; 
    }
    
    public boolean isHot() { 
        return heating; 
    } 
}

public class A_Pump implements Pump { 
    private final Heater heater; 
    
    public A_Pump(Heater heater) { t
        his.heater = heater; 
    } 
    
    public void pump() { 
        if (heater.isHot()) { 
            System.out.println("A_Pump => => pumping => =>"); 
        } 
    } 
}

이제 DI를 사용하지 않은 상태에서 메인함수에서 커피를 내려보겠습니다.

Heater heater = new A_Heater(); 
Pump pump = new A_Pump(heater); 
CoffeeMaker coffeeMaker = new CoffeeMaker(heater,pump); 
coffeeMaker.brew();

커피를 내리기 위해서는 CoffeeMaker 객체 사용자가 A_Heater 라는 인터페이스 구현체와 A_Pump 라는 구현체를 알아야 커피를 내릴수 있습니다. 사실 커피를 마시고 싶은 사람은 어떤 heater 를 쓰는지 어떤 pump 를 쓰는지 상관없는데 말이죠. 즉 CoffeeMaker 사용자가 어떤 구현체에 의존하고 있는지 알아야 합니다.

DI는 CoffeeMaker 사용자가 의존성을 모르는 상태에서도 커피를 내릴수 있도록 해줍니다. 어떤 heater 구현체를 사용해야하는지 pump 구현체를 사용해야하는지 몰라도 커피를 내릴수 있게 해줍니다. 그럼 CoffeeMaker 사용자 대신에 의존성을 주입해주는 Injection 이라는 클래스를 하나 만들어 보겠습니다.

public class Injection { 
    public static Heater provideHeater(){ 
        return new A_Heater(); 
    } 
    
    public static Pump providePump(Heater heater){ 
        return new A_Pump(heater); 
    } 
    
    public static CoffeeMaker provideCoffeeMaker(){ 
        Heater heater = Injection.provideHeater();
        return new CoffeeMaker(heater,providePump(heater)); 
    } 
}

Injection 클래스는 DI, 즉 의존성 주입을 해주는 설정 파일이라고 보시면 됩니다. 저희는 이 설정 파일에서 인터페이스 구현체를 리턴해주고 있습니다. 자 그럼 DI 를 구현한 상태에서 CoffeeMaker 사용자는 어떻게 커피를 내릴수 있을까요?

CoffeeMaker coffeeMaker = new CoffeeMaker(Injection.provideHeater(),Injection.providePump()); 
coffeeMaker.brew();

Injection 클래스에서 heater와 pump 를 제공받습니다. 이제 CoffeeMaker 사용자는 A_Heater를 사용해야하는지 B_Heater를 사용해야하는지 알 필요가 없습니다. 더 간단하게는 이렇게 구현 할 수도 있습니다.

Injection.provideCoffeeMaker().brew();

이 경우 CoffeeMaker 사용자는 heater 나 pump 가 필요한지 모르는 상태에서도 커피를 내릴수 있겠네요. 갑자기 A_Heater 말고 B_Heater 를 사용해야하는 상황이 왔을 때 DI 가 구현된 코드에서 CoffeeMaker관리자는 사용자에게 아무 얘기 없이 Injection 설정만 B_Heater로 바꿔주면 됩니다. 그러나 DI 가 구현되어 있지 않다면 CoffeeMaker 관리자는 사용자에게 커피 내릴때 A_Heater 객체 말고 B_Heater 객체 쓰렴 하며 요청해야하는 번거로운 일이 생기겠죠.

이런 형태의 디자인 패턴을 DI 라고 합니다. DI를 사용하면 코드간 커플링을 감소시킬수 있고 재사용 및 유지보수를 용이하게 할 수 있습니다. 또한 유닛 테스트 시에도 간결한 구현을 가능하게 합니다. 이런 DI를 쉽고 간결하게 해주는 프레임워크가 Dagger 입니다.

Dagger를 이용한 DI

이제 위에서 만든 CoffeeMaker 를 Dagger를 이용하여 구현해보겠습니다. 위에서 우리는 Injection 이라는 클래스를 만들어서 이곳에 의존성 주입 정보를 넣어놨습니다. Dagger에서는 이런 의존성 주입 관계를 annotation 을 이용하여 설정할 수 있습니다.

Dagger 에서 사용하는 기본적인 annotation 은 네 가지 정도가 있습니다.

@Component : 실제 의존성 주입이 구현될 interface 또는 abstract class 에 사용되는 annotation 입니다. dagger는 이 annotation 이 달려있는 인터페이스에 의존성 주입 코드를 generate 합니다. Component 클래스를 통해 우리는 의존성 주입을 할 수 있습니다.

@Module : 의존성 관계를 설정하는 클래스에 사용되는 annotation. 실제 객체 주입 관계에 대한 설정이 들어가 있습니다.

@Provides : 객체를 제공하기 위한 메서드에 달아주는 annotation 입니다.

@Inject : DI를 진행할 멤버변수와 생성자에 달아줌으로서 DI 대상을 확인할 수 있습니다. 또는 제공하고자 하는 클래스의 생성자에 달아줌으로서 제공 대상을 확인 할수 있게 해줍니다.

먼저 의존성 관계를 설정하는 클래스를 만들겠습니다. Dagger에서는 이런 클래스를 모듈이라고 부르고 @Module 이라는 annotation 을 달아 놓습니다. 모듈 클래스에서는 객체를 주입하기 위한 매서드들을 정의합니다. 우리는 heater 와 pump 인터페이스 구현체들을 주입하기 위한 매서드를 구현하겠습니다. 구현된 매서드에는 @Provides annotation 을 적용시킵니다.

@Module public class CoffeeMakerModule { 
    @Provides Heater provideHeater(){ 
        return new A_Heater(); 
    } 
    
    @Provides Pump providePump(Heater heater){ 
        return new A_Pump(heater); 
    } 
}

여기서 적용된 @Module 과 @Provides는 @Component 클래스에서 실제 주입 코드가 생성될 때 영향을 줍니다. 이제 실제 코드가 generate 되는 인터페이스인 component를 만들어 봅시다. component 에는 최소 한개의 abstract 매서드가 있어야 합니다. 그리고 그 매서드를 통해 우리는 의존성 주입을 할 수 있습니다. 그러므로 injection을 시킬 객체를 리턴하거나(provision method) 또는 맴버 파라미터로 의존성 주입을 시킬 객체를 넘기는(Members-injection methods) 매서드여야 합니다.

@Component(modules = CoffeeMakerModule.class) 
public interface CoffeeComponent { 
    //provision method 
    CoffeeMaker make(); 
    // member-injection method 
    void inject(CoffeeMaker coffeeMaker); 
}

CoffeeComponent 인터페이스를 구현하고 provision method 와 member-injection method 도 하나씩 구현해 보았습니다. 그리고 인터페이스에 component임을 알리는 @Component annotation을 달아주었습니다. @Component 에는 의존성 주입을 구현할 모듈들을 알려주어야 합니다. annotation의 modules값에 위에서 구현한 CoffeeMakerModule을 넘겨줍니다. 이제 dagger는 CoffeeMakerModule 에서 @Provides로 구현한 매서드들을 이용해서 의존성을 주입 시킬 코드를 생성합니다. 이제 @Inject 를 통해서 어디에 주입하면 되는지 알려주기만 하면 됩니다.

CoffeeComponent 인터페이스를 구현하고 provision method 와 member-injection method 도 하나씩 구현해 보았습니다. 그리고 인터페이스에 component임을 알리는 @Component annotation을 달아주었습니다. @Component 에는 의존성 주입을 구현할 모듈들을 알려주어야 합니다. annotation의 modules값에 위에서 구현한 CoffeeMakerModule을 넘겨줍니다. 이제 dagger는 CoffeeMakerModule 에서 @Provides로 구현한 매서드들을 이용해서 의존성을 주입 시킬 코드를 생성합니다. 이제 @Inject 를 통해서 어디에 주입하면 되는지 알려주기만 하면 됩니다.

@Inject 
public CoffeeMaker(Heater heater, Pump pump){ 
    this.heater = heater; 
    this.pump = pump; 
}

CoffeeMaker의 생성자에 @Inject 를 달아주었습니다. 이제 커피를 내려보는 일만 남았습니다. Dagger에서는 @Component 인터페이스를 DaggerYourComponentName 형태로 구현합니다. 여기서는 CoffeeComponent로 했으니 DaggerCoffeeComponent로 구현되어 있습니다. Component 객체는 create() 또는 build() 함수로 만들수 있습니다. 이제 커피를 내려보겠습니다.

DaggerCoffeeComponent.create().make().brew();

CoffeeComponent에서 구현했던 make 함수를 이용해서 커피를 내려보았습니다. 그럼 inject 함수는 어떻게 사용할까요? CoffeeMaker 클래스를 먼저 조금 고쳐보겠습니다.

@Inject Heater heater; 
@Inject Pump pump; 

public CoffeeMaker(){}

이제 CoffeeMaker 객체를 생성해서 inject 함수로 넘겨 의존성 주입을 해보겠습니다.

CoffeeMaker coffeeMaker = new CoffeeMaker(); 
DaggerCoffeeComponent.create().inject(coffeeMaker); 
coffeeMaker.brew();

이렇게 커피를 내릴수 있습니다.

Dagger에서는 조금 더 복잡하게 DI를 활용할 수 있도록 다양한 기능을 제공합니다. Dagger가 제공하는 몇가지 기능들에 대한 키워드를 살펴보고 예제를 통해서 어떻게 활용되는지 보겠습니다.

Subcomponent : dagger2 에는 subcomponent 를 생성할 수 있습니다. subcomponent는 말그대로 부모 component가 있는 component라고 보시면 됩니다. 다만 일반 component와는 달리 코드 생성은 부모 component에서 이루어 집니다. subcomponent는 component와 마찬가지로 interface나 abstract class에 @Subcomponent 를 달아주면서 생성 할 수 있습니다.

Scope : dagger2 는 scope 를 지원합니다. Component 별로 @scope annotation 을 이용하여 주입되는 객체들을 관리할 수 있습니다.

@Binds : module에서 제공하고자 하는 클래스의 구현체(ex interface 구현체)를 바인딩하고자 할 때 사용합니다.

Multibinding : dagger2 에서는 Set 이나 Map 을 이용한 Multibinding 을 지원합니다.

예제를 통해서 좀 더 자세히 알아보겠습니다.

이번에는 아예 CafeApp 을 만들어보도록 하겠습니다. Cafe는 CafeInfo 와 CoffeMaker 로 구성되어 있습니다.

public class CafeInfo { 
    
    private String name; 
    
    public CafeInfo(){} 
    
    public CafeInfo(String name){ 
        this.name = name; 
    } 
    
    public void welcome(){ 
        System.out.println("Welcome " + name == null? "":name ); 
    }
}

public class CoffeeMaker{ 
    private Heater heater; 
    
    @Inject public CoffeeMaker(Heater heater){ 
        this.heater = heater; 
    } 
    
    public void brew(CoffeeBean coffeeBean){ 
        System.out.println("CoffeeBeen("+coffeeBean.toString()+") [_]P coffee! [_]P "); 
    } 
}

CafeInfo 와 CoffeeMaker 를 위와 같이 구성해보았습니다. CafeInfo 는 단순히 카페이름을 가지고 있는 클래스이며 CoffeeMaker는 Heater라는 객체로 구성되어 있고 CoffeeBean을 받아 커피를 내릴 수 있는 기능이 있습니다. ( 지난 포스트 보다 업그레이드 되었습니다. 🙂 )

public class CoffeeBean { 
    public void name(){ 
        System.out.println("CoffeeBean"); 
    } 
}

자! 이제 기본적인 준비를 마쳤습니다.

이제 우리는 Dagger를 이용해 카페의 정보를 호출하고 커피를 내려보도록 하겠습니다. CafeApp 사용자는 단순히 CafeInfo를 통해 카페정보를 보거나 CoffeeMaker.brew 를 통해 커피를 내릴수 있으면 됩니다. CafeComponent에 해당 내용을 정의해보겠습니다.

@Component(modules = { CafeModule.class }) 
public interface CafeComponent { 
    CafeInfo cafeInfo(); 
    CoffeeMaker coffeeMaker(); 
}

이제 각 CafeInfo 와 CoffeeMaker 에 대한 DI 설정을 하는 CafeModule을 정의해보겠습니다.

@Module 
public class CafeModule { 
    @Provides 
    CafeInfo provideCafeInfo(){ 
        return new CafeInfo(); 
    } 
    
    @Provides 
    CoffeeMaker provideCoffeeMaker(Heater heater){ 
        return new CoffeeMaker(heater); 
    } 
    
    @Provides Heater provideHeater(){ 
        return new Heater(); 
    } 
}

이렇게 구성이 된다면 지난 포스트에서 했던 내용과 같습니다. 여기서 CafeInfo와 CoffeeMaker에 조금 더 현실을 반영해보겠습니다. 하나의 카페에 CafeInfo는 하나뿐이며 누가 보던지 같은 결과를 보여줘야 합니다. 카페가 망하기 전까지 CafeInfo는 동일합니다. 카페가 망하면 CoffeeMaker도 없어집니다. 하지만 카페가 망하지 않아도 CoffeeMaker를 새로 만들거나 교체할 수 있습니다. CoffeeMaker를 만들 때 들어가는 Heater는 같은 CoffeeMaker에 항상 같은 Heater가 들어가는 것으로 하겠습니다.

우리는 Subcomponent와 Scope 를 이용하여 Dagger에서 객체들을 위와 같이 관리 할 수 있습니다. 먼저 기본적으로 java에서 제공하는 @Singleton 과 @CoffeeScope 이라는 커스텀 annotation 을 활용하여 각 객체들의 범위를 관리해보겠습니다.

Component에 Scope annotation 을 사용하면 해당 Component에서 바인딩 되는 객체들은 Component 와 같은 라이프사이클을 가질 수 있게 할 수 있습니다.

@Singleton @Component(modules = { CafeModule.class }) 
public interface CafeComponent { 
    CafeInfo cafeInfo(); 
    CoffeeMaker coffeeMaker(); 
}

@Module 
public class CafeModule { 
    @Singleton @Provides CafeInfo provideCafeInfo(){ 
        return new CafeInfo(); 
    } 
    
    @Provides CoffeeMaker provideCoffeeMaker(Heater heater){ 
        return new CoffeeMaker(heater); 
    } 
    
    @Provides Heater provideHeater(){ 
        return new Heater(); 
    } 
}

위와 같이 Component 에 @Singleton scope 을 붙이고 Module의 CafeInfo를 제공하는 메서드에 @Singleton을 붙이면 같은 CafeComponent에서 CafeInfo 객체 호출시 동일한 CafeInfo 객체가 호출 됩니다. 그러나 @Singleton 이 없는 CoffeeMaker를 호출시에는 매번 다른 CoffeeMaker가 호출되게 됩니다.

CafeComponent cafeComponent = DaggerCafeComponent.create(); 
CafeInfo cafeInfo1 = cafeComponent.cafeInfo(); 
CafeInfo cafeInfo2 = cafeComponent.cafeInfo();

CoffeeMaker coffeeMaker1 = coffeeComponent1.coffeeMaker(); 
CoffeeMaker coffeeMaker2 = coffeeComponent1.coffeeMaker();

cafeInfo1 과 cafeInfo2 는 동일한 객체가 되지만 coffeeMaker1 과 coffeeMaker2 는 다른 객체가 됩니다.

Cafe(CafeComponent)와 CafeInfo 의 Scope 는 맞추었으니 이제 CoffeeMaker 와 Heater 의 Scope 을 맞춰보겠습니다. CoffeeMaker 의 Scope을 정의하기 위해서 CoffeeMaker를 관리하는 CoffeeComponent를 정의하겠습니다. 그리고 CoffeeComponent에는 @CoffeeScope 라는 Scope를 정의해 주었습니다. CoffeeComponent에서는 CoffeeMaker 를 얻을 수 있으며 Scope 비교를 위해서 CoffeeBean 도 얻을 수 있도록 추가해 두었습니다.

@CoffeeScope @Subcomponent(modules = { CoffeeModule.class }) 
public interface CoffeeComponent { 
    CoffeeMaker coffeeMaker(); 
    CoffeeBean coffeeBean(); 
    
    @Subcomponent.Builder interface Builder{ 
        CoffeeComponent build(); 
    } 
}

CoffeeMaker가 Cafe안에 속해있기 때문에 Component 관계 역시 상위-하위 개념을 주어야 합니다.( Cafe 를 통하지 않고서는 CoffeeMaker에 접근할 수 없도록 encapsulate 하고 Scope 역시 넓은 범위에서 좁은 범위로 진행되게 하기 위해서도 상위-하위 개념은 필요합니다. ) 이때 사용되는 것이 Subcomponent 입니다. Subcomponent는 component 와 사용방법이 유사합니다. 다만 @Subcomponent.Builder 를 정의해주어야 합니다. @Subcomponent.Builder 의 활용에 대해서는 나중에 또 설명하겠으니 일단은 @Subcomponent 는 Builder 인터페이스가 정의 되어야만 @Component 에서 코드생성이 된다라고만 알고 넘어가도록 합시다.

정의한 Subcomponent를 Component에 encapsulate 해야하는데 이때 모듈을 통해서 subcomponent와 component가 관계를 맺습니다. 위의 CafeComponent 에 CafeModule 이 적용되어 있는데요 이렇게 상위 Component에 적용된 모듈에 subcomponent를 적용시키면 component 끼리 상위-하위 관계를 맺게 됩니다. 여기서는 CafeModule에 CoffeeComponent를 적용시키겠습니다. 그리고 CafeInfo provider 메서드만 남기고 모두 삭제를 합니다.(이제는 CoffeeComponent에서 Heater 와 CoffeeMaker 를 제공하므로.)

@Module(subcomponents = CoffeeComponent.class) 
public class CafeModule { 
    //.... 
}

이렇게 @Module 에 subcomponents 를 적용 시킬수 있습니다. 이제 이 모듈을 가지고 있는 CafeComponent가 부모 컴포넌트가 되고 CoffeeComponent 가 자식 컴포넌트가 됩니다. @Subcomponent 는 @Component 뿐만 아니라 같은 @Subcomponent 끼리도 관계성을 줄 수 있습니다.

이제 CoffeeComponent 에 적용할 CoffeeModule을 정의해보겠습니다.

@Module 
public class CoffeeModule { 
    @CoffeeScope 
    @Provides 
    CoffeeMaker provideCoffeeMaker(Heater heater){ 
        return new CoffeeMaker(heater); 
    } 
    
    @CoffeeScope 
    @Provides 
    Heater provideHeater(){ 
        return new Heater(); 
    } 
    
    @Provides 
    CoffeeBean provideCoffeeBean(){ 
        return new CoffeeBean(); 
    } 
}

CoffeeMaker 와 Heater 에 대한 provider 메서드를 작성하였고 Heater와 CoffeeMaker에는 CoffeeComponent 와 같은 범위의 @CoffeeScope 로 정의하였습니다. 그리고 CoffeeBean 은 커피를 만들때마다 소모되는 것이므로 Scope 를 정의하지 않았습니다. 이제 CafeComponent에서 CoffeeComponent를 부를 수 있는 메서드를 정의하고 Scope 적용이 잘 되었나 확인해보겠습니다.

@Singleton @Component(modules = { CafeModule.class }) 
public interface CafeComponent { 
    CafeInfo cafeInfo(); 
    CoffeeComponent.Builder coffeeComponent(); 
}

CafeComponent 에서 CoffeeMaker 대신 CoffeeComponent.Builder 를 받을 수 있게 되었습니다. 이제 Scope 적용을 확인해보겠습니다.

//Scope 
CafeComponent cafeComponent = DaggerCafeComponent.create(); 
CafeInfo cafeInfo1 = cafeComponent.cafeInfo(); 

// 동일한 singleton scope 이기 때문에 같은 객체가 리턴 
CafeInfo cafeInfo2 = cafeComponent.cafeInfo(); 
System.out.println("Singleton scope CafeInfo is equal : " + cafeInfo1.equals(cafeInfo2)); 

//CoffeeScope 
CoffeeComponent coffeeComponent1 = cafeComponent.coffeeComponent().build(); 
CoffeeComponent coffeeComponent2 = cafeComponent.coffeeComponent().build(); 
CoffeeMaker coffeeMaker1 = coffeeComponent1.coffeeMaker(); 
CoffeeMaker coffeeMaker2 = coffeeComponent1.coffeeMaker(); 
System.out.println("Maker scope / same component coffeeMaker is equal : " + coffeeMaker1.equals(coffeeMaker2)); 
CoffeeMaker coffeeMaker3 = coffeeComponent2.coffeeMaker();

//MakerScopeMethod 
System.out.println("Maker scope / different component coffeeMaker is equal : " + coffeeMaker1.equals(coffeeMaker3)); 

//Non-scope 
CoffeeBean coffeeBean1 = coffeeComponent1.coffeeBean(); 
CoffeeBean coffeeBean2 = coffeeComponent1.coffeeBean(); 
System.out.println("Non-scoped coffeebean is equal : " + coffeeBean1.equals(coffeeBean2));

맨 위 부분은 이전에 설명했으니 넘어가고 CoffeeScope 부분 부터 보겠습니다. coffeeComponent1 에서 coffeeMaker1, coffeeMaker2 를 만들고 coffeeComponent2 에서 coffeeMaker3 을 만들었습니다. coffeeMaker 는 provider 메서드를 정의할 때 coffeeComponent 와 같은 @CoffeeScope 으로 정의했기때문에 coffeeComponent 당 한개의 CoffeeMaker 만 존재할 것입니다. 그러므로 결과는 coffeeMaker1 = coffeeMaker2 != coffeeMaker3 이 됩니다.

이제 Non-scope 부분을 확인하겠습니다. CoffeeModule 에서 CoffeeBean provider메서드는 scope설정을 하지 않았습니다. 그러면 같은 coffeeComponent 에서 CoffeeBean 을 생성해도 서로 다른 CoffeeBean 이 나오게 됩니다. 그러므로 coffeeBean1 != coffeeBean2 가 됩니다.

이제 위에서 지나쳤던 @Component.Builder 과 @Subcomponent.Builder 를 살펴봅시다. Dagger는 component 를 생성할 때 builder pattern을 사용합니다. @Component 의 경우 코드가 generate 되기 때문에 기본적으로 builder 역시 generate 됩니다. 그러나 @Subcomponent 는 @Component 클래스 안에서 코드가 생성될 때 @Subcomponent.Builder 가 붙은 interface 가 없으면 builder 가 자동으로 생성되지 않습니다. 그러므로 @Subcomponent.Builder 가 꼭 필요합니다. Builder 에는 build 하기 전에 모듈을 파라미터로 넣을 수 있습니다. 이는 멤버변수를 가지고 있는 모듈이 있을 때 유용하게 사용할 수 있습니다. 위에서 정의한 CafeModule을 아래와 같이 변경해봅시다.

@Module(subcomponents = CoffeeComponent.class) 
public class CafeModule { 
    private String name; 
    public CafeModule(){ } 
    public CafeModule(String name){ 
        this.name = name; 
    } 
    
    @Singleton 
    @Provides 
    CafeInfo cafeInfo(){ 
        if(name == null || name.isEmpty()) 
            return new CafeInfo(); 
        else return new CafeInfo(name);
    } 
}

이제 CafeModule 은 생성자에서 카페 이름을 받을 수 있고 이것을 CafeInfo 를 생성할 때 사용 할수 있게 되었습니다. 이제 CafeComponent 에서 Component Builder를 만들어 봅시다.

public interface CafeComponent { 
    CafeInfo cafeInfo(); 
    CoffeeComponent.Builder coffeeComponent(); 
    
    @Component.Builder 
    interface Builder{ 
        Builder cafeModule(CafeModule cafeModule); 
        CafeComponent build(); 
    } 
}

이렇게 build 하기 전에 CafeModule 을 적용 시킬 수 있도록 해두었습니다.

CafeComponent cafeComponent = DaggerCafeComponent.builder() 
        .cafeModule(new CafeModule("example cafe")) 
        .build(); 
cafeComponent.cafeInfo().welcome();

그럼 위 코드 처럼 CafeComponent 생성시 카페이름을 적용한 모듈을 미리 bind 시킬 수 있고 이를 통해서 카페이름을 갖게 된 CafeInfo 를 제공 받을수 있게 됩니다.

지금까지 Subcomponent 과 그와 관련된 내용에 대해서 알아보았습니다.

이제 @Binds, MultiBinding 에 대해서 알아보겠습니다. @Binds는 추상메서드를 이용해서 좀 더 간략하게 binding을 구현할 때 사용합니다. 예제를 통해서 알아보겠습니다.

먼저 CoffeeBean 을 상속한 EthiopiaBean 을 정의해보겠습니다.

public class EthiopiaBean extends CoffeeBean{ 
    public void name(){ 
        System.out.println("EthiopiaBean"); 
    } 
}

만약 어떤 모듈에서 EthiopiaBean 의 provider 메서드를 제공하고 있거나 EthiopiaBean 이 @Inject 를 통해 Injectable 한 것으로 정의 되어 있다면

@Binds 
abstract CoffeeBean provideCoffeeBean(EthiopiaBean ethiopiaBean);

이렇게 추상메서드로 정의하는 것만으로 CoffeeBean 객체를 제공받을 수 있습니다. 이제 MultiBinding 에 대해서 알아보겠습니다. Dagger 는 한 객체가 여러가지 형태로 binding 가능 할 때 Set 이나 Map을 이용해서 MultiBinding 이 가능합니다. 예제를 보며 살펴보겠습니다.

이번에는 CoffeeBean 을 상속받은 GuatemalaBean 을 하나 만들어 보겠습니다.

public class GuatemalaBean extends CoffeeBean { 
    public void name(){ 
        System.out.println("GuatemalaBean"); 
    } 
}

그리고 GuatemalaBean 도 EthiopiaBean 처럼 CoffeeBean 으로 바인딩 시키려고 하면 CoffeeBean 객체 제공시 혼란을 가져오게 됩니다. 이때 MultiBinding 을 이용하여 특정 객체를 바인딩 시킬 수 있습니다.

@Binds 
@IntoMap 
@StringKey("ethiopia") 
abstract CoffeeBean provideEthiopiaBean(EthiopiaBean ethiopiaBean); 

@Binds 
@IntoMap 
@StringKey("guatemala") 
abstract CoffeeBean provideGuatemalaBean(GuatemalaBean guatemalaBean); 
// EthiopiaBean 처럼 @Provide method 를 제공하지 않아도 @Inject annotation을 이용해 Injectable 한 객체로 정의해도 bind 가능.

@IntoMap 과 @StringKey 를 이용하여 Map 형태로 MultiBinding 한 코드입니다. Map으로 MultiBinding 된 것은 Map<key,object> 형태로 제공됩니다.

Map<String,CoffeeBean> coffeeBeanMap(); // in CoffeeComponent

CoffeeComponent coffeeComponent = DaggerCafeComponent.create().coffeeComponent().build(); 
coffeeComponent.coffeeBeanMap().get("guatemala").name();

위와 같이 활용 될 수 있습니다.

마치며

이번 포스트에서는 간단한 DI예제로 DI에 대해서 살펴보았고 cafe예제를 만들어보면서 DI를 활용했을 때 어떤 장점들이 있는지, DI tool 들은 이런 장점을 쉽게 적용시키기 위해 어떤 기능들을 제공하는지 dagger 를 활용하여 살펴보았습니다. DI에 대해서 이해하고자 하시는 분들께 조금이나마 도움이 되었으면 합니다.

저희 모바일팀에서는 Android의 경우 Hilt, iOS의 경우 Swinject을 통해 DI를 구현하고 있습니다. 다음 Part2. 포스트에서는 각 플랫폼 별로 다양한 상황에서의 DI를 어떻게 적용하는지, 모바일팀에서 DI를 적용하는 구체적인 방법과 Hilt, Swinject를 어떻게 활용하는지에 대해 소개하도록 하겠습니다.