DI 입문 - 종속 항목 삽입

https://developer.android.com/training/dependency-injection?hl=en&_gl=1*1qv5x8w*_up*MQ..*_ga*MzAxOTAwMTAzLjE3MDk3ODMyNjQ.*_ga_6HH9YJMN9M*MTcwOTc4MzI2My4xLjAuMTcwOTc4MzI2My4wLjAuMA..#kotlin

Android의 종속 항목 삽입  |  Android 개발자  |  Android Developers

먼저 종속 항목 주입 없는 쌩 코드를 먼저 보자.

class Engine{
    fun start(){
        println("시동 걸기")
    }
}

class Car {
    private val engine = Engine()

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

fun main(){
    val di = Car()
    di.start()
}

Engine의 생성자를 직접 호출해서 Engine의 instance를 만들고, 그 메서드를 호출하는 방식으로 클래스 간 메서드 사용을 했다면 다음과 같은 방법으로 바꿔볼 수 있다. 

상위 컴포넌트가 하위 컴포넌트에 바로 접근하지않고, 상위컴포넌트도 하위컴포넌트를 주입받는 형태로, 컨트롤 반전(Inversion Of Control)을 기반으로 한 의존성 주입(Dependency Injection)이 이뤄진다. 

DI?

DI를 쓰는 이유는 크게 세 가지로 요약할 수 있다.

• 클래스 재사용 가능 및 종속 항목 분리
  • 받아올 종속 항목을 쉽게 교체할 수 있다. 클래스가 더 이상 종속 항목 생성 방법을 제어하지 않고 대신 모든 곳에서 꺼내 쓸 수 있다.(컨트롤 반전)
• 리팩터링 편의성
  • 종속 항목을 인터페이스를 통해 확인할 수 있고 구현 세부정보로 숨겨지지 않고(클래스 내부에서 생성) 객체 생성 시간 또는 컴파일 시간에 확인할 수 있다.
• 테스트 편의성
  • 클래스는 종속 항목을 관리하지 않으므로 테스트 시 다양한 구현을 전달하여 다양한 모든 사례를 테스트할 수 있다. 테스트를 진행해보진 않아서 이 부분에 대해서는 경험해볼 필요가 있다...

컨트롤 반전?

컨트롤 반전은 소프트웨어 디자인 패턴 중 하나로, 의존성의 제어 흐름을 역전시킴으로써 시스템의 모듈화와 유연성을 향상시킨다. 일반적인 제어 흐름은 일반적으로 고수준 모듈이 저수준 모듈에 의존하는 방식으로 이루어진다. 컨트롤 반전을 사용하면 저수준 모듈이나 외부 리소스에 대한 제어를 고수준 모듈이 직접하지 않고, 대신 외부에서 이를 주입받아 사용한다.

flowchart TD
    Hilt--> UseCase
    Hilt <--> repo

생성자 주입 / 필드 주입으로 나눠볼 수 있다.

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

fun main(){
    val engine = Engine()
    val di = Car(engine)
    di.start()
}

생성자주입은 Engine을 생성자로 받아서 멤버변수로 처리하여 engine의 start 메서드를 처리할 수 있다. Car의 종속항목인 Engine을 생성자로 주입받은 코드다. ⇒ 생성자 주입

class Engine {
    fun start() {
        println("Engine started")
    }
}

class Car {
    lateinit var engine: Engine

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

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

필드 주입은 생성자로 접근하진 않지만 종속항목을 따로 관리해줘야한다. 종속항목을 사용하기 전에 car의 멤버에 초기화해주는 과정을 거쳐야한다.

 

이전 까지는 수동으로 종속항목을 직접 주입, 관리했다. ⇒ 종속항목이 많아지거나 종속 항목을 전달하기 전에 구성할 수 없을 때는 관리가 매우 까다로워진다.(생명주기를 개발자가 생각해서 짜야된다.) 특히 종속항목을 lazy하게 선언했으면 메모리에서 해당 종속 항목의 전체 기간을 관리하는 맞춤 컨테이너(또는 종속 항목 그래프)를 작성하고 유지해야 한다. 이게 까다로운데, 이걸 라이브러리한테 넘기는게 Dagger, Hilt다.

 

라이브러리를 사용하지 않고 관리하려면 싱글톤으로 서비스 로케이터를 생성해서 거기서 종속항목을 받아오는 형태로 구현할 수도 있다.

object ServiceLocator { //singleton으로 초기화됨.
    fun getEngine(): Engine = Engine()
}

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

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

fun main(args: Array){

}

싱글톤으로 생성해서 쓰니까 얼핏보기엔 팩토리패턴을 사용하면서 꽤 분리된 것 처럼 보인다. 문제는 종속 항목이 API 노출 영역(인터페이스)이 아닌 클래스 구현에서 인코딩 된다는 것이다. object는 클래스 선언과 동시에 싱글톤으로 선언하는 것이다. 따라서 클래스가 외부에서 필요한 것이 무엇인지 알기가 더 어려워지고 결과적으로 Car 또는 서비스 로케이터에서 종속 항목 정보를 변경하면 참조가 실패하여 런타임 오류 또는 테스트 실패가 발생할 수 있다.

 

수동으로 의존성 주입하는 과정을 경험해볼 건데, Hilt라는 라이브러리리가 있다. Hilt는 Dagger를 계승한 라이브러리로 프로젝트의 모든 Android 클래스에 컨테이너를 제공하고 수명 주기를 자동으로 관리한다. 컨테이너는 일종의 객체 팩토리 역할을 한다고 할 수 있는데 애플리케이션의 구성 요소들 간의 의존성을 관리하고 필요한 객체를 생성하고 제공하는 역할을 한다. 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^