2week_AOS_tech_post_3

DI, Hilt 뽀개기

---

Hilt란?

안드로이드 개발을 해보면 의존성 주입, 의존성 주입 라이브러리, Hilt 같은 단어들을 많이 듣게 됩니다.

의존성은 또 뭐고, 그걸 또 주입??… Hilt는 또 뭐야 듣기만 해도 머리가 어지러워 지는 기분이에요~

자 ~ 그러면 지금부터 천천히 step by step으로 한번 알아가 봐요!

우선 Hilt 의존성 주입 라이브러리를 알기 전에 의존성이 뭔지 알아야 할 필요가 있어요

저희 함께 의존성이 뭔지 함께 알아가 볼까요?

---

DIP (Dependency Inversion Principle)

의존 역전의 원칙이라고도 불리는 요놈은 어디서 나온 말일까요?

DIP는 객체지향설계 5원칙(SOLID)에서 D에 해당하는 원칙이며 의존 역전의 법칙이라고도 합니다.

의존 역전의 원칙

의존 관계를 맺을을 때 변하기 쉬운 것에 의존하기 보다는 변화하지 않는 것에 의존하라!

위의 말은 어떤 의미가 담겨 있을까요?

예를 들어

저희가 쇼핑물에서 사용자가 물건을 구입하면 구입한 내역을 알려주기 위해 알림 기능을 구현한다고 생각해 봅시다.

이메일로 사용자에게 알려주기로 결정을 했고 아래와 같이 기능을 구현 했습니다

class EmailMessenger {
    fun sendNotification(message: String): String{
        println("Sending email: $message")
    }
}

class NotificationService {
    private val messenger = EmailMessenger()

    fun sendNotification() {
        messenger.sendNotification("구입 내역에 대해 안내 드립니다.")
    }
}

하지만 문제가 있네요!

문자 알림 서비스를 만들어 달라고 요청이 들어오거나 이메일 메신저 기능을 바꿔달리는 요구사항이 생기면 어떻게 될까요?

NotificationService 클래스는 EmailMessenger 클래스에 의존성을 가지고 있다고 할 수 있는데 ,

EmailMessenger 클래스에 변화가 생기면 EmailMessenger 클래스를 참조하는 모든 클래스를 수정해줘야 하는 상황이 생기겠죠?

한번에 직관적으로 이해가 안되시죠? 어떤 상황일지 궁금하실분 들이 있을 것 같아요

백문불여일견이라는 말이 있듯이 함께 아래 예제를 한번 같이 봐볼까요?

아래 예제 처럼 EmailMessenger의 sendNoticifation 메소드가 이제 문자열 매개 변수 대신 객체를 받도록 변경 되었다고 가정해 봅시다.

data class EmailMessage(val content: String, val id: Int)

class EmailMessenger {
    fun sendNotification(message: EmailMessage): String{
        println("Sending email: ${message.content}")
    }
}

NotificationService 클래스에서는 sendNoticifation() 메소드를 호출할 때 문자열 대신 EmailMessenger 객체를 전달하도록

변경해야합니다.

class NotificationService {
    private val messenger = EmailMessenger()

    fun sendNotification() {
        messenger.sendNotification(EmailMessage("구입 내역에 대해 안내 드립니다.", 1))
    }
}

음? 그냥 바꾸면 되는거 아닌가?? 라고 생각하실 수 도 있어요!

이렇게 간단한 예제에서는 그냥 바꾸고 말지 하는데 만약 NotificationService 클래스처럼 EmailMessenger 클래스를 의존하는 클래스가

엄청 많아진다면 어떻게 할까요?

피 같은 시간에 그걸 일일이 바꾸고 있으면 눈물이 절로 날거에요 🥲

이렇게 하나의 클래스가 다른 클래스에 의존하는 경우, 후자가 변경되면 전자도 그에 따라 변경해야 하는 상황이 발생할 수 있습니다.

이런 상황을 피하기 위해 의존성 주입을 사용하여 클래스 간의 결합도를 낮출 수 있습니다.

그러면 첫 번째 예제의 코드에 대해 리팩토링 과정을 거쳐서 조금 더 유지보수가 쉬운 코드로 작성해 봅시다!

우선 공통 부분을 추상화한 Interface를 구현한 뒤

interface Messenger {
    fun sendNotification()
}

구현 클래스들을 만들어 줍니다.

class EmailMessenger() : Messenger {
    override fun sendNotification(): String {
        return "Sending email:"
    }
}

class SMSMessenger() : Messenger {
    override fun sendNotification(): String {
        return "Sending SMS"
    }
}

비지니스 로직을 담당하는 클래스를 만들어 준 뒤

class NotificationService(private val messenger: Messenger) {
    fun sendNotification(message: String) {
        println(messenger.sendNotification() + message)
    }
}

아래와 같이 사용할 수 있게 됩니다.

class NotificationServiceTest {
    @Test
    fun sendNotification_givenEmail_shouldReturnEmailMessage() {
        // Given
        val notificationService = NotificationService(EmailMessenger())

        // When
        val message = emailService.sendNotification("구입 내역에 대해 안내해 드립니다")

        // Then
        assertEquals("Sending email:구입 내역에 대해 안내해 드립니다", message);
    }

  @Test
   fun sendNotification_givenSms_shouldReturnSmsMessage() {
        // Given
        val notificationService = NotificationService(SMSMessenger())

        // When
        val message = notificationService.sendNotification("구입 내역에 대해 안내해 드립니다")

        // Then
        assertEquals("Sending SMS:구입 내역에 대해 안내해 드립니다", message);
    }
}

위와 같은 설계를 하게 된다면,

외부에서 EmailMessenger의 인스턴스를 생성해 NotificationService 클래스 객체를 만들 때 생성자로 주입을 해주게 된다면

EmailMessenger클래스에 수정이 일어나더라도 NotificationService클래스를 수정할 필요가 없게 됩니다.

위 처럼 코드를 작성하면 NotificationService 클래스는 인제 Messenger 인터페이스에 의존하게 되므로 EmailMessenger 클래스나

SMSMessgenger 클래스과 같은 변하기 쉬운 클래스 보다 더 변하지 않는 Messenger 인터페이스에 의존하게 되므로 코드의 유연성이 높아지게 되었네요.

Messenger 인터페이스의 구현이 추가 되더라도 NotificationService 클래스를 변결할 필요가 없어졌습니다.

DI를 하는 이유나 장점은 뭘까요?

• boilerplate code를 줄여주므로 유연한 프로그래밍이 가능해 집니다.
• 재사용성이 높아지고 유지보수가 더 쉬워집니다.
• 더 편한 유닛 테스트가 가능해집니다.
• 결합도를 낮추어서 확장성을 높여 줍니다.

---

Hilt?

그렇다면 의존성 역전의 법칙에 대해 알아 봤으니 이것을 조금 더 쉽게 구현해주는 라이브러리 Hilt에 대해 함께 알아봐요

Hilt는 Android에서 Dependency Injection를 쉽게 구현할 수 있도록 돕는 도구입니다.

필요한 의존성을 제공하는 **Module**을 작성하고, 필요한 곳에 @Inject 주석을 사용하여 의존성을 주입받습니다.

Hilt는 이러한 작업을 자동화하여 코드를 깔끔하게 유지하고 테스트를 용이하게 해줍니다.

그럼 Hilt를 사용했을 때와 사용하지 않았을 때의 예제를 한번 봐볼까요?

Hilt를 사용하지 않고 생성자 주입을 통해 의존성을 주입 하는 경우

class CarRepository(private val apiService: ApiService) {
    // ...
}

class MainActivity : AppCompatActivity() {
    
    // 직접 인스턴스를 생성하여 주입
    private val apiService = ApiService()
    private val userRepository = UserRepository(apiService)
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
    }
}

Hilt를 사용하는 경우

@Module
@InstallIn(SingletonComponent::class)
object AppModule {

    @Provides
    @Singleton
    fun provideApiService(): ApiService {
        return ApiService()
    }
}

class CarRepository @Inject constructor(private val apiService: ApiService) {
    // ...
}

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    
    // Hilt를 통해 자동으로 의존성 주입
    @Inject
    lateinit var userRepository: UserRepository
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
    }
}

• 위 예제에서 보이듯이 Hilt를 사용하면 ApiService 인스턴스 생성 및 **CarRepository**에 주입하는 코드를 명시적으로 작성할 필요가 없어집니다.
• Hilt는 의존성 주입 코드를 간소화하고 자동화 함으로써 코드의 복잡성을 줄여주고 관리를 더 쉽게 해줍니다.

---

Hilt 사용 예

**Application 클래스에 Hilt 초기화**

@HiltAndroidApp
class CarArtApplication : Application()

CarExteriorImageRepository를 제공하는 모듈을 작성 (Optional)

• RepositoryModule 클래스는 Hilt를 사용하여 의존성 주입을 설정할 때 사용되는 모듈 클래스입니다.
• Hilt의 모듈은 의존성 그래프에 객체를 제공하는 방법을 정의합니다.
• 즉, 어떤 타입의 객체를 요청할 때 어떤 구현체 또는 인스턴스를 제공해야 하는지 Hilt에 알려주는 역할을 합니다.
• 모듈 클래스를 언제 작성하는지?

  • 모듈 클래스가 필요 없는 경우

    단순한 의존성 (생성자 주입 가능):

    단순한 의존성은 주로 다음과 같은 특징을 갖습니다.

    • 클래스의 생성자가 다른 의존성 없이 쉽게 인스턴스화될 수 있습니다.
    • 클래스의 생성자에 필요한 파라미터들이 이미 Hilt에 의해 제공될 수 있는 타입이거나, 그 자체로 주입 가능한 다른 클래스들입니다.

    예제:

    kotlinCopy code
    class UserService @Inject constructor(private val api: UserApi) {
        // 여기서 UserApi는 Hilt가 알고 있는 타입이거나 다른 곳에서 주입될 수 있는 타입이어야 합니다.
    }

    위의 **UserService**는 UserApi 타입만 필요로 하며, 이 **UserApi**가 Hilt에 의해 이미 주입 가능한 타입이라면, **UserService**는 자동으로 주입될 수 있습니다

  • 모듈 클래스가 필요한 경우

    복잡한 의존성 (모듈이 필요한 경우):

    복잡한 의존성은 주로 다음과 같은 특징을 갖습니다.

    • 인스턴스 생성에 특별한 조건이나 로직이 필요합니다.
    • 설정 값, 환경 값, 플래그 등에 따라 다르게 생성되어야 하는 경우가 있습니다.
    • 특정 인터페이스를 구현하는 여러 구현체 중에서 하나를 선택해야 할 때가 있습니다.

    예제

    kotlinCopy code
    @Module
    @InstallIn(SingletonComponent::class)
    object NetworkModule {
        @Provides
        fun provideApiService(@Named("apiUrl") apiUrl: String): ApiService {
            return Retrofit.Builder()
                .baseUrl(apiUrl)
                .addConverterFactory(GsonConverterFactory.create())
                .build()
                .create(ApiService::class.java)
        }
    }
    

    위의 예제에서 **ApiService**의 생성은 Retrofit 설정과 함께 특정 URL에 기반하여 이루어지기 때문에, 단순한 생성자 주입만으로는 처리하기 어렵습니다. 따라서 @Provides 어노테이션이 붙은 메서드를 사용하여 **ApiService**의 인스턴스 생성 방법을 지정해야 합니다.

  • 단순한 의존성은 Hilt가 이미 알고 있는 타입들만을 생성자의 파라미터로 사용하므로, 그냥 @Inject 어노테이션을 붙여주면 됩니다.

  • 복잡한 의존성은 특정한 로직이나 설정에 따라 객체가 생성되어야 할 때 발생하며, 이런 경우에는 모듈 내의 @Provides 메서드를 통해 인스턴스 생성 방법을 지정해줘야 합니다.

• 어떤 기준으로 모듈 클래스를 나눠야하지?
  1. 기능 별: 각 기능이나 화면(예: 로그인, 사용자 프로필, 주문 등)에 대해 별도의 모듈로 분리
  2. 계층 별: 애플리케이션의 아키텍처 계층(예: 데이터, 도메인, 프레젠테이션)에 따라 모듈을 분리
  3. 라이브러리 별: 서드파티 라이브러리 또는 특정 프레임워크와 관련된 의존성을 제공하는 모듈을 만듭니다. 예를 들어, Retrofit 관련 의존성을 제공하는 **NetworkModule**이나, Room 데이터베이스 관련 의존성을 제공하는 **DatabaseModule**을 생각해볼 수 있습니다.
  4. 스코프 별: 특정 스코프(예: 애플리케이션, 액티비티, 프래그먼트 등)에 대한 의존성만을 제공하는 모듈을 생성합니다. SingletonModule, ActivityModule, **FragmentModule**과 같은 이름으로 네이밍 될 수 있습니다.
  5. 환경 별: 개발, 스테이징, 프로덕션과 같은 다른 환경에 따라 다르게 동작해야 하는 의존성이 있는 경우, 각 환경에 맞는 모듈을 만듭니다.
  6. 테스트용 모듈: 테스트 시 사용하는 의존성을 제공하는 모듈을 생성합니다. 이를 통해 실제 운영 환경과는 다른 모의(Mock) 객체나 가짜(Fake) 객체를 주입할 수 있습니다.

@Module
@InstallIn(SingletonComponent::class)
object RepositoryModule {
    
    @Provides
    @Singleton
    fun provideCarExteriorImageRepository(): CarExteriorImageRepository {
        return CarExteriorImageRepository()
    }
    
    // ... 기타 제공 메서드 ...
}

ViewModel에서 의존성 주입하기

class CarColorChoiceViewModel @Inject constructor(
    private val imageRepository: CarExteriorImageRepository
) : ViewModel() {
    // ... 나머지 코드는 그대로 유지 ...
}

Fragment에서 뷰 모델 주입

import dagger.hilt.android.AndroidEntryPoint
import javax.inject.Inject

@AndroidEntryPoint
class CarColorChoiceFragment() : Fragment(), OnOtherColorItemClickListener {
    private var _binding: FragmentCarColorChoiceBinding? = null
    private val binding get() = _binding!!
    
    // ViewModel 주입
    private val carColorChoiceViewModel by viewModels<CarColorChoiceViewModel>()

    // ... 나머지 코드 ...

}

---

Hilt 어노테이션

1. @Singleton:
   • 이 주석은 해당 의존성이 싱글턴으로 동작해야 함을 나타냅니다. 즉, 해당 객체는 앱의 생명주기 동안 하나만 생성되며 여러 번 요청되어도 동일한 인스턴스를 반환합니다.
   • 예를 들어, 어떤 서비스나 데이터베이스와 같은 객체가 앱 전체에서 하나만 존재해야 할 때 유용하게 사용됩니다.
2. @Provides:
   • @Provides 주석은 Hilt에게 어떻게 특정 타입의 인스턴스를 제공해야 하는지 알려줍니다. 이 주석이 달린 메서드는 해당 타입의 객체를 생성하고 반환합니다.
   • @Module 내부에서 사용되며, 필요할 때마다 Hilt에 의해 호출되어 해당 타입의 인스턴스를 제공합니다.
3. @Module:
   • @Module 주석은 해당 클래스가 Hilt 모듈임을 나타냅니다. 모듈은 의존성 주입을 위해 객체를 제공하는 메서드들의 집합입니다.
   • Hilt는 이 모듈을 사용하여 필요한 의존성들을 어떻게 생성하고 제공해야 하는지 알게 됩니다.
4. @InstallIn:
   • @InstallIn 주석은 모듈이 어느 컴포넌트에 설치되어야 하는지 지정합니다.
   • 예를 들어, **@InstallIn(SingletonComponent::class)**은 해당 모듈이 Singleton 스코프를 가진 컴포넌트에 설치되어야 함을 나타냅니다. 따라서 이 모듈에 있는 @Provides 메서드들이 제공하는 의존성들은 싱글턴으로 동작할 것입니다.
5. @AndroidEntryPoint:
   • Hilt를 사용하여 Android 클래스에 의존성을 주입하기 위한 주석입니다. 이 주석을 Activity나 Fragment와 같은 Android 컴포넌트에 붙이면, Hilt는 그 컴포넌트에 필요한 의존성을 자동으로 제공합니다.
   • 예를 들면, **@AndroidEntryPoint**가 붙은 Fragment에서는 Hilt가 해당 Fragment에 필요한 객체들을 알아서 주입해줍니다.

---

📚Refernece

Hilt를 사용한 종속 항목 삽입  |  Android 개발자  |  Android Developers

Hilt를 사용하여 안드로이드 MVVM 아키텍쳐 구현하기