[Android] 일반적인 UseCase 패턴 실수

https://proandroiddev.com/common-android-usecase-pattern-mistakes-382b6d0e7c03

Common Android UseCase Pattern Mistakes

 

이 포스팅은 위 링크를 번역한 것이다.

 

유스케이스는 복잡한 앱 로직을 간단하고 재사용 가능한 부분으로 구성하는 데 도움이 되는 도구다.

앱에서 수행해야 하는 특정 task나 operation을 담는 컨테이너라고 생각하면 된다. 각 유스케이스는 1가지 일을 잘해야 한다는 규칙을 따른다. 아래는 유스케이스를 사용하는 것의 장점이다.

 

• 앱 여러 부분에서 코드 재사용성 촉진
• 비즈니스 로직, 구현 세부 사항을 분리해서 정리 가능
• 복잡한 비즈니스 운영(operation)을 분리해서 테스트 가능성 향상
• 유지보수, 수정이 용이한 모듈식 아키텍처 지원

 

안드로이드 앱 개발에서 난 2가지 일반적인 실수를 봤다.

 

• 엄격한 뷰모델-유스케이스 전용 접근을 적용하는 것
• repository 함수와 유스케이스 간의 1:1 매핑 만들기

 

엄격한 뷰모델-유스케이스 전용 접근 적용

 

일반적인 구현 패턴은 뷰모델이 유스케이스에만 접근할 수 있도록 엄격하게 적용해서 repository에 직접 접근하는 걸 완전히 제한한다. 이 접근법은 도메인 계층 패턴의 일부지만 구글 안드로이드 팀은 이걸 선택사항으로 유지할 것을 권장한다.

 

https://developer.android.com/topic/architecture/domain-layer?hl=ko

 

이 결정은 앱의 요구사항에 따라 달라져야 한다.

이런 제한은 종종 유스케이스 클래스의 폭발적 증가로 이어진다. repository에 함수가 10개면 해당되는 유스케이스도 10개 만들게 된다. 뷰모델이 repository의 기능 대부분을 요구한다면 하나의 repository 주입이 여러 유스케이스 주입보다 더 효율적일 수 있다.

 

repository 함수, 유스케이스 간의 1:1 매핑

 

2번째 실수는 단순히 repository 함수를 프록시하는 유스케이스를 만드는 것이다. repository의 getUser()만 호출하고 리턴하는 GetUserUseCase를 만드는 것이 그것이다. 때로는 개발자가 간단한 mapper를 추가하지만 본질적으로 동일한 1:1 관계를 유지하는 경우도 있다. 이 경우엔 뷰모델에서 직접 repository에 접근하는 게 더 적절할 수 있다.

 

적절한 유스케이스 구현

 

유스케이스는 복잡한 비즈니스 로직을 처리하도록 특별히 설계됐다. 아래는 구글의 도메인 계층에서 잘 구현된 유스케이스 예시다.

 

/**
 * This use case fetches the latest news and the associated author.
 */
class GetLatestNewsWithAuthorsUseCase(
  private val newsRepository: NewsRepository,
  private val authorsRepository: AuthorsRepository,
  private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    suspend operator fun invoke(): List<ArticleWithAuthor> =
        withContext(defaultDispatcher) {
            val news = newsRepository.fetchLatestNews()
            val result: MutableList<ArticleWithAuthor> = mutableListOf()
            // This is not parallelized, the use case is linearly slow.
            for (article in news) {
                // The repository exposes suspend functions
                val author = authorsRepository.getAuthor(article.authorId)
                result.add(ArticleWithAuthor(article, author))
            }
            result
        }
}

 

이 유스케이스는 여러 repository의 데이터를 결합하고 비즈니스 로직을 수행해서 새 모델을 만드는 적절한 구현을 보여준다.

좋은 접근법은 필요할 때만 유스케이스를 추가하는 것이다. 뷰모델, repository 사이의 필수 계층이 아닌 캡슐화해야 하는 복잡한 비즈니스 로직이 있을 때 사용해야 한다.

 

유스케이스를 구현할 때는 복잡한 비즈니스 로직을 캡슐화한다는 기본 목적에 집중하라. 불필요한 추상화를 피하고 유스케이스가 정말 필요한지 평가하라. 캡슐화할 복잡한 비즈니스 로직이 없으면 repository 직접 접근도 충분히 허용된다는 점을 기억하라.