[Android] Dependency Injection Part 1. Overview

이 글은 Android Developer 가이드 내용을 토대로 작성되었습니다. 예제 코드는 Kotlin만 가져왔으며, Java 코드는 원문에서 확인할 수 있습니다.

의존성 주입(Dependency injection, DI)은 프로그래밍에서 널리 사용되고, Android 개발에 적합한 기술입니다. DI의 원칙을 따르면 좋은 앱 아키텍처의 기반을 갖출 수 있습니다.

DI를 통해 얻을 수 있는 장점

• 코드 재사용 가능
• 리팩토링 용이
• 테스트 용이

DI의 기본 개념

Android에서의 DI를 살펴보기 전에, 이 파트에서는 DI의 동작 방식에 대한 좀 더 기본적인 개념을 설명합니다.

의존성 주입이란?

한 클래스에서 다른 클래스 참조는 자주 필요합니다. 예를 들어, Car 클래스는 Engine 클래스를 참조해야 합니다. 이렇게 필요한 클래스를 디펜던시라고 합니다. 그리고 이 예시에서 Car 클래스는 실행시 Engine 인스턴스를 갖는 것에 의존합니다.

클래스에 필요한 객체를 얻는 방법은 3가지가 있습니다:

1. 클래스가 필요한 디펜던시를 생성한다. Car 클래스가 Engine 인스턴스를 직접 생성하고 초기화
2. 다른 어딘가에서 가져온다. getContext()나 getSystemService() 같은 몇몇 Android API가 이렇게 동작함
3. 파라미터를 통해 받는다. 클래스가 생성될 때 또는 각 디펜던시마다 필요한 함수의 파라미터를 통해 전달받을 수 있다. Car 생성자의 파라미터로 Engine을 전달받는다.

세 번째 방법이 바로 DI 입니다! 이 방법을 통해 클래스에 인스턴스를 포함시키지 않고도 의존성을 얻거나 제공할 수 있습니다.

아래는 의존성 주입없이 Car 클래스가 Engine 인스턴스를 직접 생성하는 예시 코드입니다.

class Car {

    private val engine = Engine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}

이 코드는 아래의 이유로 문제가 될 수 있는 코드입니다.

• Car와 Engine이 단단히 연결되어 있습니다 - Car 인스턴스가 Engine이라는 한 가지 타입을 사용하여, 서브 클래스나 대체할 구현체를 쉽게 사용할 수 없습니다. Car 자체에서 사용할 Engine을 직접 생성하므로, Gas나 Electric 엔진 타입이 추가되면 Car를 재사용할 수 없고 두 가지 Car 타입을 새로 만들어야 합니다.
• Engine에 대한 단단한 의존성은 테스트도 더욱 어렵게 만듭니다. Car가 실제 Engine 인스턴스만 사용하기 때문에 여러 테스트 케이스를 위한 Engine의 Mock 객체 사용이 어렵습니다.

의존성 주입을 사용하면 코드가 어떻게 변경될까요? Car 인스턴스마다 초기화 시점에 Engine을 생성하지 않고, Car 생성자의 파라미터를 통해 전달받습니다.

class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.start()
}

main 함수에서 Car를 사용합니다. Car가 Engine에 의존하기 때문에 Engine 인스턴스를 먼저 생성하여 Car 인스턴스 생성 시 사용합니다. DI 기반의 접근법은 아래의 장점을 가집니다:

• Car 재사용 가능 - Engine의 다른 구현체를 Car에 전달할 수 있습니다. 예를 들어, ElectricEngine이라는 Engine의 새로운 서브 클래스를 정의했을 때, DI를 사용한다면 Car 클래스 변경없이 ElectricEngine만 Car에 전달하면 됩니다.
• Car 테스트 용이 - 여러 시나리오 테스트를 위한 객체를 전달할 수 있습니다. 예를 들어, FakeEngine이라는 Engine의 테스트용 객체를 만들어 각 테스트 케이스에 맞게 설정할 수 있습니다.

Android에서 의존성 주입 방법은 크게 2가지가 있습니다:

• 생성자 주입: 위 코드에서 설명한 방식으로, 디펜던시를 생성자에 전달합니다.
• 필드 주입(또는 Setter 주입): Activity나 Fragment 같은 특정 Android Framework 클래스들은 시스템에 의해 생성되어, 생성자를 통한 의존성 주입이 불가능합니다. 필드 주입을 사용하면 클래스 생성 이후에 의존 관계를 나타낼 수 있습니다. 아래 코드가 필드 주입 예시입니다.

class Car {
    lateinit var engine: Engine

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.engine = Engine()
    car.start()
}

DI 자동화

위에서 본 DI 예제 코드는 모두 다른 클래스에 대한 의존 관계를 직접 생성, 전달, 관리했습니다. Car 클래스가 지금은 하나의 디펜던시만 갖지만 디펜던시와 클래스가 늘어남에 따라 복잡도 또한 증가하게 됩니다.

규모가 큰 앱의 경우, 모든 디펜던시를 얻어서 알맞게 연결하기 위한 많은 양의 보일러플레이트 코드가 생기게 됩니다. Multi-layered architecture의 경우, 상위 계층애서 필요한 객체를 생성하기 위해 하위의 모든 디펜던시를 전달해야 합니다.

그래서 디펜던시를 생성하고 전달하는 과정을 자동화하기 위한 라이브러리들이 있습니다. Java, Kotlin 그리고 Android의 의존성 주입 라이브러리로는 Google의 Dagger가 많이 쓰이고 있습니다.

DI의 대안 - Service Locator

DI 대신 Service Locator 디자인 패턴을 사용할 수도 있습니다. Service Locator 또한 클래스간 단단한 연결고리를 분리하는 데 도움을 줍니다. 보통 ServiceLocator라는 클래스를 만들고, 디펜던시를 생성해서 저장해뒀다가 필요한 경우 전달하는 로직을 담습니다.

object ServiceLocator {
    fun getEngine(): Engine = Engine()
}

class Car {
    private val engine = ServiceLocator.getEngine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}

Service Locator 패턴은 클래스가 주도권을 가지고 주입되어야 할 클래스를 요청하지만, DI는 앱이 주도권을 가지고 필요한 클래스를 사전에 주입합니다.

앱의 규모에 따라 알맞은 방법 선택하기

먼저 프로젝트의 규모는 어떻게 파악할까요? 여기서는 앱의 사이즈가 큰가 작은가를 화면 개수로 정할 수 있습니다. 물론 화면의 개수는 앱의 크기를 결정하는 많은 요소 중 하나일 뿐입니다.

• 직접 의존성 주입: 확장성이 좋지 않으므로 비교적 작은 앱에만 적합합니다. 프로젝트 크기가 커질수록 보일러플레이트 코드도 증가합니다.
• Service Locator: 보일러플레이트 코드가 비교적 적지만 확장성이 좋지 않습니다. 싱글톤 객체에 의존하므로, 테스트 또한 어렵습니다.
• Dagger: 확장성이 좋고, 복잡한 앱에도 적합합니다.

현재는 작은 앱인데 규모가 커질 것으로 예상된다면, 더 많은 코드가 변경되기 전에 미리 Dagger로 전환하는 것이 좋습니다.

라이브러리 규모에 따라 알맞은 방법 선택하기

SDK나 라이브러리를 개발하고 있다면 수동 DI 또는 규모에 따라 Dagger를 사용하세요. 다만 의존성 주입을 위해 3rd party 라이브러리를 사용하면 라이브러리의 크기 또한 증가할 수 있다는 점은 주의가 필요합니다.

결론

DI를 사용하면 아래와 같은 장점이 있습니다.

• 코드 재사용 가능 및 의존성 분리: 구현체를 변경하기 쉬워집니다. 클래스가 더이상 디펜던시들이 어떻게 생성되는지 신경쓰지 않아도 되고, 제어의 역전 덕분에 코드의 재사용성이 증가합니다.
• 리팩토링 용이: 의존 관계가 API에 분명히 드러나기 때문에, 구현체의 숨겨진 내용을 보지 않고 객체 생성 시점 또는 컴파일 시점에만 확인하면 됩니다.
• 테스팅 용이: 클래스가 자신의 의존 관계를 관리하지 않기 때문에, 테스트 시 각 테스트 케이스에 맞는 구현체를 전달하기만 하면 됩니다.

DI의 장점을 완벽하게 이해하려면 앱에 직접 써보는 것이 좋습니다. 다음 파트에서 직접 의존성을 주입하는 방법으로 돌아오겠습니다!