DI

https://geekflare.com/fullstack-development-frameworks-libraries/

DI (Dependency injection / 의존성 주입) 이란?

우선 안드로이드 DI 를 적용하면 훌륭한 앱 아키텍처를 위한 토대를 마련할 수 있다. 안드로이드 공식문서에 따르면 DI 를 적용하면 아래와 같은 이점이 누릴 수 있다.

• 코드 재사용 가능

• 리팩토링 편의성

• 테스트 편의성

이 글을 작성하면서 나 스스로 위에 이점들을 잘 누리고 있었는지 되돌아 볼 것이다.

우선 클래스에는 다른 클래스 참조가 필요하다. 예를 들어 Car 클래스는 Engine 클래스 참조가 필요할 수 있다. 이처럼 필요한 클래스를 종속 항목(dependencies) 이라고 하며, Car 클래스가 실행되기 위해서는 Engine 클래스의 인스턴스가 필요하다.

클래스가 필요한 객체를 얻는 방법은 3가지가 있다.

• 클래스가 필요한 종속 항목 (Engine Class) 을 구성한다. 위 예에서는 Car 클래스는 자체 Engine 인스턴스를 생성하여 초기화한다.

• 다른 곳에서 객체를 가져온다. Context getter & getSystemService() 와 같은 일부 Android API는 여러한 방식으로 작동한다.

• 객체를 매게변수로 제공받는다. 앱은 클래스가 구성될 때 이러한 종속 항목을 제공하거나 각 종속 항목이 필요한 함수에 전달할 수 있다. 위 예에서는 Car 생성자는 Engine 을 매개변수로 받는다.

여기서 말하는 3번째 방법이 바로 DI / 의존성주입이다 🔥 이 방법을 사용하면 클래스 인스턴스가 자체적으로 종속 항목을 얻는 대신 클래스의 종속 항목을 받아서 제공한다.

우선 1번과 같은 방법으로 인스턴스화 하는거는 아래 코드와 같다.

class Car {

    private val engine = Engine()

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

class Engine {
    fun start() {
        // write code...
    }
}

이 예는 Car 클래스가 자체 Engine 을 객체생성 후 사용하기 때문에 DI 가 아니다. 또한 아래와 같은 문제가 발생할 수 있다.

• Car 와 Engine 은 밀접하게 연결되어있다. Car 인스턴스는 한 가지 유형의 Engine 을 사용하므로 서브클래스 또는 대체 구현을 쉽게 사용할 수 없다. Car 가 자체 Engine 을 구성했다면 Gas / Electric 유형의 엔진에 동일한 Car 를 재사용하는 대신 두 가지 유형의 Car을 생성해야 한다.

• 위 예제와 같이 의존성이 높은 경우 다양한 테스트 케이스에서 테스트를 더욱 어렵게 만든다.

DI 정의

의존성 주입은 하나의 객체가 다른 객체의 의존성을 제공하는 기술이다.

의존성 주입은 광범위한 역제어 테크닉의 한 형태이다. 어떤 서비스를 호출할려는 클라이언트는 그 서비스가 어떻게 구성되었는지 알지 못해야 한다. 클라이언트는 대신 서비스 제공에 대한 책임을 외부 코드(주입자)로 위임한다. 클라이언트는 주입자 코드를 호출할 수 없다. 그 다음 주입자는 이미 존재하거나 주입자에 의해 구성되었을 서비스를 클라인트로 주입한다. 그리고 나서 클라이언트는 서비스를 사용한다. 의존성 주입은 네 가지 역할을 담당하는 객체 및 인터페이스를 전제로 한다.

• 사용될 서비스 객체 - 전기, 가스, 하이브리드 또는 디젤 자동차

• 사용하는 서비스에 의존하는 클라이언트 객체 - 엔진에 상관 없이 동일하게 차를 사용하는 운전자

• 클라이언트의 서비스 사용 방법을 정의하는 인터페이스 - 운전자가 기어와 같은 엔진의 세부 사항을 이해할 필요가 없도록 보장해주는 자동변속기

• 서비스를 생성하고 클라이언트로 주입하는 책임을 갖는 주입자 - 아이에게 어떤 차를 사줄지 결정하고 구매해준 부

DI 접근방식

1. 생성자 삽입

class Car(private val engine: Engine) {

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

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

2. 필드 삽입

class Car() {
    lateinit var engine: Engine

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

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

위 예제와 같은 DI 기반 접근방법의 이점은 다음과 같다.

• Car 의 재사용가능. Engine 의 다양한 구현을 Car 에 전달할 수 있다. 예를 들어 GasEngine 을 사용하는 경우, Engine 클래스를 상속받아 서브클래스를 정의할 수 있다. GasEngine 을 인스턴스로 전달하면 Car 클래스는 아무런 변경없이 사용할 수 있다.

• 테스트 더블을 전달하여 다양한 시나리오 테스트를 할 수 있다.

이전 예에서는 라이브러리를 사용하지 않고 직접 생성 및 관리를 하였다. 이를 직접 종속 | 수동 항목 삽입 이라고 한다. 종속 항목이 많아 질 수록 종속 항목을 삽입하는 작업이 지루해 질 수 있다. 뿐만 아니라 다음과 같은 문제점들이 있다.

• 대규모 앱의 경우 모든 종속 항목을 가져와 올바르게 연결하려면 대량의 상용구 코드가 필요하다. 예로, 자동차를 만들려면 엔진,변속기 기타 부품 엔진에는 실린더, 점화 플로그 등이 필요로 하다.

• 종속 항목을 전달하기 전에 구성할 수 없을 때는 메모리에서 종속 항목의 전체 기간을 관리하는 맞춤 컨테이너를 작성하고 유지해야 한다.

이러한 문제점들을 해결하는 라이브러리들이 존재하며, 이는 두 가지 카테고리로 분류된다.

• 런타임 시 종속 항목을 연결하는 리플렉션 기반 솔루션 - Koin...

• 컴파일 타임에 종속 항목을 연결하는 코드를 생성하는 정적 솔루션 - Dagger / Hilt...

Dependency injection in Android  |  Android DevelopersAndroid Developers

Reference

의존성 주입Wikipedia

Reference