Singleton vs Dependency Injection
해당 글에서 보다보면 막히는 부분이 있다.
The heuristic to determine whether you need to introduce a singleton is simple. If a dependency cross-cuts most of your classes and/or several layers in your application, extract it using the Singleton pattern. Otherwise, use the standard Dependency Injection technique. The ultimate goal is to make sure that you don’t use DI for ambient dependencies.
싱글턴을 도입해야 하는지 판단하는 휴리스틱은 간단합니다. 만약 의존성이 대부분의 클래스와/또는 애플리케이션의 여러 레이어를 가로지른다면, 싱글턴 패턴을 사용하여 이를 추출하세요. 그렇지 않다면, 표준 의존성 주입 기법을 사용하세요. 궁극적인 목표는 주변 의존성에 대해 DI를 사용하지 않도록 하는 것입니다.
“여러 레이어를 가로지른다” 는 무슨뜻인가?
예를 들어, NetworkService 는 ViewModel이나 Service 레이어에서만 필요하다. 굳이 View가 알 필요가 없다. 하지만 로그나 날짜 포맷팅, 분석과 같은 기능들은 어떨까?
- View: 버튼 눌렀을 때 로그를 남김
- ViewModel: 데이터를 변환할 때 로그를 남김
- Repository: DB 에러 났을 때 로그를 남김
이처럼 모든 층에서 공통적으로 필요해서 이것이 레이어를 가로지르는 의존성이다. 만약 로그 같은 기능을 모든 곳에 DI로 넣어주려 한다면, Constructor Pollution 이 발생한다. 만약 사용하지 않는 View가 있다고 한들, ViewModel에게 넘겨주기 위해 갖고 있어야 한다.
요약
적절하게 싱글턴과 DI를 판단하고 사용해야 한다.
싱글턴을 써도 되는 경우
- 로그
- 환경 설정
- 분석
싱글턴을 쓰면 안되는 경우
- APIClient, DataBaseManager : 이건 싱글턴으로 만들면 테스트가 불가능해지고, 앱의 동작을 제어하기가 힘들어진다.
다음은 DIContainer 를 주제로 정리해서 들고오겠습니다 !
읽어주셔서 감사합니다! 오타 및 잘못된 내용은 언제든 댓글 달아주시면 최대한 빠르게 수정하겠습니다!
