https://dagger.dev/users-guide
Dagger는 FactoryFactory 클래스를 대체한다. 보일러플레이트를 배제한 의존성주입을 구현한다. 이는 쓸모없는 오버엔지니어링을 방지하고 의미 있는 클래스에 집중할수 있게 한다. 의존성을 정의하고 어떻게 구성되는지 기술하면 된다.
테스트 시 아주 유용할뿐 아니라 재사용 가능하고 모듈의 변경이 가능하다. AuthenticationModule을 여러 앱에서 사용 가능하고 DebugLoggingModule과 ProdLoggingModule을 상황에 맞게 구성하여 사용할 수 있다.
Dagger2는 최초료 풀스택 코드생성방식으로 구현되었다.
커피메이커 샘플(https://github.com/google/dagger/tree/master/examples/simple/src/main/java/coffee)로 대거를 설명하겠다.
대거는 당신의 클래스들과 이에 관련된 의존성을 정의하는 것으로 구성이 된다. Javax.inject.Inject 어노테이션으로 각 생성자와 필드를 지정한다.
클래스 생성자에 @Inject를 사용하면 대거가 클래스인스턴스를 만들때 사용한다. 새로운 인스턴스를 요청하면 요구되는 파라메터들을 얻어내어 생성자를 만든다.
class Thermosiphon implements Pump {
private final Heater heater;
@Inject
Thermosiphon(Heater heater) {
this.heater = heater;
}
...
}
대거는 필드를 바로 주입할수 있다. 다음 샘플은 두개의 필드를 얻어낸다.
class CoffeeMaker {
@Inject Heater heater;
@Inject Pump pump;
...
}
클래스가 @Inject 필드는 있는데 생성자가 @Inject가 없다면 대거는 필요하면 필드를 주입하게 되겠지만 새로운 인스턴스를 생성하지는 않을 것이다. 인자가 없는 생성자를 추가해서 대거가 인스턴스를 생성할 수 있게 해주어야 한다.
메서드 주입도 지원하는데 생성자나 필드주입이 선호된다.
@Inject아너테이션이 없는클래스는 대거가 생성할 수 없다.
기본적으로 위에서 기술한 타입의 인스턴스를 생성함으로써 의존성을 만족시킨다. CoffeeMaker를 요청하면 new CoffeeMaker()로 인스턴스를 만들고 필드에 주입하도록 설정한다.
@Inject가 항상 동작하지는 않는다.
- Interface는 생성될수 없다.
- 3rd party 클래스는 어도테이션할수 없다.
- 설정가능한 객체는 반드시 설정하여 사용해야 한다.
@Providers 어노테이션은 메서드에 의존성을 부여한다. 해당 메서드의 반환타입이 의존성객체이다.
예를 들어 provideHeader()는 Header가 필요할대 마다 호출된다.
@Module
class DripCoffeeModule {
@Provides static Heater provideHeater() {
return new ElectricHeater();
}
@Provides static Pump providePump(Thermosiphon pump) {
return pump;
}
}
@Inject와 @Provides 로 어노테이트된 클래스는 의존성에 따른 객체 그래프를 만든다. main메서드나 안드로이드의 Application이 그래프의 루트로 사용될수 있다.
대거2에서 의존성은 다음 샘플처럼 인수가 없고 원하는 형식을 반환하는 메서드가 있는 인터페이스로 정의되며 @Component주석과 모듈유형을 매개변수로 전달한다. 그러면 명세에 따라 코드가 생성된다.
@Component(modules = DripCoffeeModule.class)
interface CoffeeShop {
CoffeeMaker maker();
}
프리픽스로 Dagger가 붙은 동일한 이름의 클래스가 생성되며 builder().build()메서드로 인스턴스를 얻는다.
CoffeeShop coffeeShop = DaggerCoffeeShop.builder()
.dripCoffeeModule(new DripCoffeeModule())
.build();
콤포넌트가 최상위타입이 아니면 생성된 콤포넌트 이름은 타입의 이름을 포함하여 밑줄로 구분하여 이름이 정해진다.
class Foo {
static class Bar {
@Component
interface BazComponent {}
}
}
이 경우 DaggerFoo_Bar_BazComponent
접근가능한 생성자를 갖는 모듈은 builder가 생략될 수 있다.
모든 @Provides메서드가 static이면 인스턴스의 구현이 필요없다. 이 때도 create()메서드로 builder없이 생성이 가능하다.
CoffeeShop coffeeShop = DaggerCoffeeShop.create();
커피앱에서 대거가 생성한 구현체가 주입된 CoffeeShop객체를 사용하는 예이다.
public class CoffeeApp {
public static void main(String[] args) {
CoffeeShop coffeeShop = DaggerCoffeeShop.create();
coffeeShop.maker().brew();
}
}
위 샘플은 콤포넌트를 어떻게 생성하는지에 대한 몇가지 방법을 설명한다. 다른 바인딩방법을 알아보자
다음은 의존성으로 사용 가능하며 잘 구성된 콤포넌트를 생성하는데 사용될 수 있다.
- @Component.modules에 의해 직접 참조되거나 @Module.includes를 통해 참조죄는 @Module내에 @Provides메서드로 선언된 모듈
- scope이 지정되지 않는 @Inject생성자가 있는 타입이거나 콤포넌트 scope에 일치하는 @Scope 주석이 있는 타입
- 콤포넌트 의존성의 콤포넌트 제공 메서드
- 콤포넌트 자체
- 임의의 포함된 서브콤포넌트의 규정되지 않는 빌더
- Provider 또는. Lazy wrapper
- Lazy의 Provider( Provider<Lazy<CoffeeMaker>>)
- 모든 타입의 memberInjector
@Singletone주석을 갖는 @Provides는 단일인스턴스를 사용한다.
@Provides @Singleton static Heater provideHeater() {
return new ElectricHeater();
}
싱글톤을 사용할떄는 멀티스레드에 대해 대비해야 한다.
@Singleton
class CoffeeMaker {
...
}
대거2는 콤포넌트 구현 시 범위를 연관시키기 때문에 이를 선언해야 한다. @Singletone과 @RequestScoped바인딩을 동일한 콤포넌트에 포함하는것은 의미가 없다. 수명주기가 다르기 때문인데 유의하여 각 콤포넌트 인터페이스 정의 시 범위 주석을 적용해야 한다.
@Component(modules = DripCoffeeModule.class)
@Singleton
interface CoffeeShop {
CoffeeMaker maker();
}
콤포넌트는 여러 범위 주석을 적용할 수 있다.
간혹 @Inject로 생성되는 클래스가 @Provides메서드로 인스턴스로 만드는데 회수를 제한하고자 할수 있다. 하지만 모든 개개의 콤포넌트나 서브콤포넌트에서 사용되는 인스턴스가 동일한지 보장할 필요 없다. 이는 안드로이드 같은 메모리가 비용이 비싼 경우 유용하다.
이 경우 @Reusable 범위를 사용할 수 있다. @Reusable이 사용되면 다른 범위와 다르게 모든 단일 콤포넌트에 연관되지 않는다 대신에 각 바인딩을 실제로 사용하는 콤포넌트들은 캐시하거나 객체를 생성한다.
이는 콤포넌트에 @Reusable이 바인딘된 모듈을 정의하고 서브콤포넌트만 실제 해당 바인딩을 사용한다면 서브콤포넌트는 해당 바인딩을 캐시하게 된다. 조상을 공유하지 않는 두개의 서브콤포넌트가 바인딩 한다면 각각 따로 캐시할것이다. 조상이 이미 객체를 캐시한 경우 서브컴포넌트는 재사용한다.
콤포넌트가 바인딩을 한번만 호출한다는 보장이 안되므로 변경가능한 객체를 반환하는 바인딩에 @Reusable을 적용하거나 동일 인스턴트를 참조하는것은 위험하다. 할당 횟수와 상관없는 불변객체에 대해 사용하는것이 안전하다.
@Reusable // It doesn't matter how many scoopers we use, but don't waste them.
class CoffeeScooper {
@Inject CoffeeScooper() {}
}
@Module
class CashRegisterModule {
@Provides
@Reusable // DON'T DO THIS! You do care which register you put your cash in.
// Use a specific scope instead.
static CashRegister badIdeaCashRegister() {
return new CashRegister();
}
}
@Reusable // DON'T DO THIS! You really do want a new filter each time, so this
// should be unscoped.
class CoffeeFilter {
@Inject CoffeeFilter() {}
}
Lazy injections
지연된 주입이 가능하다. 샘플 참조.
class GrindingCoffeeMaker {
@Inject Lazy<Grinder> lazyGrinder;
public void brew() {
while (needsGrinding()) {
// Grinder created once on first call to .get() and cached.
lazyGrinder.get().grind();
}
}
}
Provider Injections
여러개의 인스턴스가 필요한 경우가 있을 것이다. 이 경우 사용이 가능하다.
class BigCoffeeMaker {
@Inject Provider<Filter> filterProvider;
public void brew(int numberOfPots) {
...
for (int p = 0; p < numberOfPots; p++) {
maker.addFilter(filterProvider.get()); //new filter every time.
maker.addCoffee(...);
maker.percolate();
...
}
}
}
Qualifier
같은 클래스의 다른 인스턴스가 필요한 경우가 있다. 이 경우 qualifier주석을 사용할 수 있다.
@Qualifier
@Documented
@Retention(RUNTIME)
public @interface Named {
String value() default "";
}
자신만의 qualifier를 만들거나 그냥 @Named를 사용할수 있다. 필드와 관심있는 파라메터에 모두 사용가능하다.
class ExpensiveCoffeeMaker {
@Inject @Named("water") Heater waterHeater;
@Inject @Named("hot plate") Heater hotPlateHeater;
...
}
대응되는 @Provides메서드가 제공되어야 한다.
@Provides @Named("hot plate") static Heater provideHotPlateHeater() {
return new ElectricHeater(70);
}
@Provides @Named("water") static Heater provideWaterHeater() {
return new ElectricHeater(93);
}
Optional bindings
콤포넌트에 포함되지 않음에도 디펜던시를 추가하고 싶다면 @BindsOptionalOf를 사용할 수 있다.
@BindsOptionalOf abstract CoffeeCozy optionalCozy();
이는 @Inject생성자와 멤버 그리고 @Provides메서드는 Optional<CoffeeCozy>객체에 의존한다. 콤포넌트에 CoffeeCozy가 바인딩되어 있으면 Optional이 존재하고 없으면 존재하지 않을것이다.
다음중 하나를 주입할수 있다.
- Optional<CoffeeCozy> : CoffeeCozy의 바인딩에 @Nullable이 없다면(아래 참조)
- Optional<Provider<CoffeeCozy>>
- Optional<Lzay<CoffeeCozy>
- Optional<Provider<Lazy<CoffeeCozy>>>
Provider, Lazy 또는 Lazy의 Provider를 주입할수 있지만 유용하지는 않다.
CoffeeCozy바인딩이 있고 바인딩이 @Nullable이면 Optional<CoffeeCozy>에서 컴파일에러가 발생한다. 왜냐하면 Optional은 null일수 없기 때문이다. Provider나 Lazy는 get 메서드에서 항상 null을 반환할 수 있기 때문에 항상 다른 값이 주입될 수 있다.
콤퍼넌트에 optional 바인딩이 없어도 서브콤포넌트에 있을 수 있다. 서브콤포넌트에 기저타입의 바인딩이 있다면…
Binding Instances
종종 콤포넌트를 빌드하는 시점에 유효한 데이터를 가질수 있다. 예를 들어 커맨드라인 인자를 필요로 하는 앱이 있는 경우 콤포넌트에 인자를 전달하고자 할것이다.
단일 인자로 이름을 받고 @UserName문자열로 주입하고자 한다면 콤포넌트 생성시 값을 전달하기 위해 @BindsInstance 주석을 추가할수 있다.
@Component(modules = AppModule.class)
interface AppComponent {
App app();
@Component.Builder
interface Builder {
@BindsInstance Builder userName(@UserName String userName);
AppComponent build();
}
}
위와 같이 정의하고 앱에서는 아래와 같이 사용한다.
public static void main(String[] args) {
if (args.length > 1) { exit(1); }
App app = DaggerAppComponent
.builder()
.userName(args[0])
.build()
.app();
app.run();
}
콤포넌트에 주입되는 @UserName 문자열은 이 메서드가 호출될 때 빌더에 제공되는 인스턴스에 사용하게 될것이다. 콤포넌트를 빌드하기 전에 모든 @BindsInstance메서드들이 반드시 호출되어야 하면 null이 아닌값이 전달되어야 한다(@Nullable 바인딩의 경우 제외).
@BindsInstance메서드가 @Nullable인 경우 바인딩은 @Provides메서드의 경우처럼 nullable로 간주된다. @Nullable로 해야 하며 이 떄는 바인딩에 null이 허용된다. Builder의 유저는 호출을 생략할수 있으며 이 경우 콤포넌트는 null로 다루어진다.
@BindsInstance메서드는 @Module에 생성자 인자로 작성되어야 하고 해당 값이 바로 제공되어져야 한다.
Compile-time Validation
대거 아노테이션 프로세서는 업격해서 유효하지 않거나 완성되지 않는 바인딩에 대해 컴파일에러를 발생한다. 예를 들면 다음 예는 Executor를 위한 바인딩이 누락상태의 모듈을 콤포넌트에 인스톨하고 있다.
@Module
class DripCoffeeModule {
@Provides static Heater provideHeater(Executor executor) {
return new CpuHeater(executor);
}
}
컴파일하면 javac는 바인딩 누락으로 반려하게 된다.
[ERROR] COMPILATION ERROR :
[ERROR] error: java.util.concurrent.Executor cannot be provided without an @Provides-annotated method.
콤포넌트내의 아무 모듈에든 executor를 위한 @Provides 주석을 추가해서 문제를 해결할 수 있다. @Inject, @Module그리고 @Provides주석이 각각 유효하면 @Component단계에서 바인딩간의 관계에 대한 모든 유효성검사가 발생한다. 대거1은 모듈단계에서 유효성이 업격하게 책임지없다면 대거2는 이 단계는 생략한다.
Compile time Code Generation
대거는 컴파일 시 CoffeeMaker_Factory.java나 CoffeeMaker_MembersInjector.java같은 이름의 파일들을 만들어 낸다. 이 파일들은 대거 구현의 디테일이다. 이들을 바로 사용할일은 없으며 디버깅은 해볼수 있겠다.코딩 시 참조할만한 코드들은 콤포넌트에 프리픽스로 Dagger를 붙이것들이다.
Using Dagger In Your Build
Dagger-2.x.jar가 런타임에 필요하다. dagger-compiler-2.x.jar는 코드자동생성을 위해 필 요하다. 자새한것은 다음 링크 참조 https://github.com/google/dagger/blob/master/README.md#installation
