Dependency Injection

노준혁·2023년 2월 12일

Constructor Injection Field Injection dagger dependency injection di hilt

https://developer.android.com/training/dependency-injection
https://tecoble.techcourse.co.kr/post/2021-04-27-dependency-injection/

DI(dependency injection):
A클래스가 실행되기 위해서는 B클래스의 인스턴스가 있어야 함.
이러한 경우 A클래스는 B클래스에 의존성을 가진다 함.
A클래스는 B클래스가 있어야만 실행가능 하기 때문.

ex) 토비의 스프링에서,

A가 B를 의존한다. ->

의존대상인 B가 변하면, A에 영향을 준다.
B의 로직이 변경되면 A에도 변화를 준다는 의미로 설명

클래스가 필요한 객체를 얻는 3가지 방법
- A클래스가 필요한 dependency인 B클래스를 자체적으로 생성해 초기화하는 경우
- 다른 곳에서 객체를 가져옴. ex) Context getter등
- 객체를 매개변수로 제공받음
  앱은 클래스(A클래스가)가 생성될 때 생성자로 이러한 dependencies(B클래스)들을 제공받음.

객체를 매개변수로 제공받는 것이 Dependency injection!
매개변수로 제공받기에 클래스 인스턴스가 자체적으로 dependency를 얻는 대신 외부에서 해당 클래스들을 제공받음

A클래스가 B클래스를 DI없이 자체적으로 생성해서 사용한다면 다음과 같은 문제 발생

class Car { // 이 Car 클래스는 단 하나의 Engine에 대해서만 실행되는 로직
	private val engine = Engine()
    
    fun start() {
    	engine.start()
    }
}

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

A클래스와 B클래스는 밀접하게 연결됨.
-> A클래스는 한가지 유형의 B클래스만 사용하기에 subClasses나 alternative implementation이 어려움.
A클래스가 자체 B클래스를 구성했으면 B-1클래스나 B-2클래스로 A클래스에 DI하지 못하고 A클래스를 각각 따로 따로 만들어야 함. (A+(B-1), A+(B-2))

A클래스가 B클래스를 DI 한다면?
A클래스가 생성될 때 B클래스 객체를 생성하는 대신 B클래스 객체를 생성자의 매개변수로 받음.

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

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

Car는 Engine에 의존하게 됨. (=Car는 Engine에 종속됨)
앱은 Engine 인스턴스를 만들고 이것을 Car인스턴스를 만드는데 사용함.
이러한 DI 접근의 이점은 다음과 같음.

Engine의 다양한 implementataion(=구현체)를 Car에서 사용할 수 있음.
DI를 사용한다면, ElectricEngine이라는 새로운 Engine의 서브클래스를 정의한 후 이 업데이트된 ElectricEngine 서브클래스의 인스턴스를 Car의 매개변수에 전달하기만 하면 Car는 추가적인 내부로직 변경 없이도 같은 로직의 동작을 수행할 수 있음.
테스트의 편의성 증가 -> 테스트에 맞게 다양한 인스턴스를 생성해 적용해볼 수 있음.

Android에서 DI를 실행하는 두 가지 주요 방법

Constructor Injection (생성자 주입) : dependencies를 클래스의 생성자에 주입
Field Injection(=Setter Injection) : Activity, fragment 같은 클래스는 시스템에서 인스턴스화를 진행하므로 생성자주입이 불가능. -> dependencies를 클래스가 생성된 후 인스턴스화 함

class Car {
	lateinit var engine : Engine
    
    fun start() {
    	engine.start()
    }
}

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

DI 라이브러리를 사용하지 않고 DI 로직을 위 예제처럼 직접 구현하는 것을 dependency injection by hand, or manual dependency injection이라 함.
위 예제에서는 Car클래스는 Engine이라는 하나의 dependency만을 필요로 하기에 간단해 보이지만, Engine말고도 다른 부품(변속기, 바퀴 등)에 대한 dependency 혹은 Engine 또한 실린더와 점화 플러그를 dependency로 필요로 하기에 복잡한 작업이 된다.

auto DI 라이브러리 = Hilt

DI를 위한 Android JetPack의 권장 라이브러리
Hilt는 프로젝트의 모든 Android 클래스에 컨테이너를 제공하고 수명 주기를 자동으로 관리함으로써 애플리케이션에서 DI를 실행하는 표준 방법을 정의함.
Hilt는 Dagger(DI라이브러리)를 기반으로 빌드되었으며, Dagger가 제공하는 compile time correctness, runtime performance, scalability(확장성)등의 이점을 가져옴.

DI 장점

Reusability of classes and decoupling of dependencies(dependencies 분리)
주입받는 대상이 변하더라도(B클래스가 변하더라도) A클래스에서는 로직을 수정할 필요가 없거나 줄어들게 된다.
(의존성이 줄어든다. <=> 분리된다.)
Ease of refactoring
Ease of testing

https://youtu.be/ZNnz6vpMgrU

의존성 주입은 객체지향 프로그래밍 개념 중 하나
객체 지향 설계의 5대 원칙인 SOLID 원칙을 기반으로 함.
SOLID 원칙
- 단일 책임 원칙(Single responsibility principle, SRP)
  : 클래스가 여러 개의 책임을 가지게 되면, 각 책임마다 클래스를 변경할 수 있는
  이유가 생길 수 있기에 클래스 마다 책임을 단 한개만 가지도록 설계해야 함.
  Work클래스는 다음과 같이 4개의 책임을 수행하는 로직으로 구성되어 있는데,
  4개의 책임 중에 하나만 변경이 되더라도 Work클래스는 수정되어야 하며, Work클래스와 연계된 클래스 또한 변경되어야 함.
  
  그래서, 이 Work 클래스를 4개의 클래스로 나눠 기능을 유연하게 변경할 수 있도록 해야 함.
- 개방-폐쇄 원칙 (Open-closed principle, OCP)
  : 객체를 수정하지 않고도 기능이 확장 가능하도록 설계해야 된다는 원칙.
  
  네트워크에서 데이터를 읽어오는 DataReader 클래스가 있을 때, 네트워크에서 데이터를 다운로드하는 기능은 NetworkAccess클래스에서 담당하도록 구현.
  DataSource interface를 만들어서 NetworkAccess가 상속하도록 만든다.
  
  로컬 파일에서 데이터를 읽어오는 기능을 추가하고 싶으면 이 기능을 구현하는 FileAccess클래스를 만들고 DataSource interface를 상속하게 하면 됨.
  그러면, DataReader는 DataSource를 참조하고 있기 때문에 내용을 변경하지 않고도 파일에서 데이터를 읽어오는 기능을 추가할 수 있다.
  기능을 확장하는 부분은 interface를 사용해서 추상화하고, 새로운 기능 추가는 상속을 적용해서 클래스를 유연하게 변경할 수 있게 된다.
- 리스코프 치환 원칙 (Liskov substitution principle, LSP)
  : 상위 타입 객체가 하위 타입 객체로 변환되어도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다는 원칙.
  
  네모 클래스와 정사각형 클래스는 더 추상화된 Shape 객체를 추가로 만들어서 Rectangle과 Square가 모두 Shape를 상속하게 하고 Shape의 면적을 계산하는 함수를 만드는게 적절.
  LSP를 위반한다는 것은 하위타입이 상위타입의 명세를 제대로 지키지 않고 있다는 뜻.
- 인터페이스 분리 원칙(Interface segregation principle, ISP)
  : 구현할 필요가 없는 메소드를 가진 interface를 객체에 사용하지 말라는 뜻.
  
  Lion은 날지 못지 못하는데 Animal을 상속했기에 의무적으로 fly메소드를 구현해줘야 된다.
  따라서, 이런 경우 interface를 나눠서 만들어주는 것이 좋다.
  
  Animal을 위와 같이 분리해서 사용해야 된다.
- 의존성 역전 원칙(Dependency inversion principle, DIP)
  : 의존성이란, 객체 A가 객체 B를 생성하거나, 객체 B의 메소드를 호출할 때,
  객체 A가 객체 B에 의존한다 혹은 의존성 B를 갖는다고 표현함.
  (객체 A= 상위 레벨 모듈, 객체 B= 하위 레벨 모듈)
  
  Car클래스가 Engine 클래스에 의존하고 있음.
  DIP에 따르면, 상위 레벨 모듈은 하위 레벨 모듈에 의존해서는 안되고 추상화에 의존해야 한다.
  ex) 자동차 = 상위레벨 모듈, 엔진,타이어,핸들 등 = 하위레벨 모듈

만약, 가솔린엔진을 디젤엔진으로 바꾼다고 하면

Car클래스 내부에서 객체 생성을 다르게 해주게 되는데,
이는 상위레벨 모듈인 Car클래스가 바뀌는 것이기에 DIP를 위반하는 경우이다.
즉, 하위레벨모듈인 엔진이 바뀌더라도(가솔린->디젤) Car클래스에서는 수정되는 코드가 없어야 된다는 것이다.

해결하기 위해서는,
현재 Car는 GasolineEngine에 의존하고 있지만, GasolineEngine은 아무 것도 의존하지 않고 있다.

따라서, 이 흐름 중간에 엔진 interface를 도입하면, 의존이 없었던 하위레벨 모듈인 GasolineEngilne이 역으로 상위 레벨모듈인 Engine레 의존하게 되는 의존관계 역전이 일어남. Car는 Engine에 의존하고 있기 때문에 Gasoline에서 Diesel로 갈아끼우더라도 DIP를 위반하지 않는다.

의존성 주입(Dependency Injection, DI)
의존관계는 꼬리에 꼬리를 무는 특징이 있음.
(Piston변경 시 Engine과 Car 또한 변경됨)

순환참조 :Piston 변경 시 다시 자기 자신인 Piston이 변경되는 문제
-> 유지보수를 어렵게 함.
-> 의존 역전 원칙으로 이를 해결 -> 의존성 주입으로 의존 역전 원칙 수행
-> 따라서, 의존성 주입이 중요!
-> 의존성 주입을 개발자가 모두 관여하기에는 복잡하기에 라이브러리를 이용(Hilt,Dagger,Koin 등)
상위 모듈인 Car에서 engine을 직접 생성하면 의존성 역전 원칙과 확장 폐쇄 원칙까지 위배
의존성 주입 방법 3가지