후우 오랫만에 미션이군요

기능 요구 사항 생성자 주입 - 수동 다음 문제점을 해결한다.

• 테스트하기 어렵다.
• Repository 객체를 교체하기 위해 또다른 객체를 만들어 바꿔줘야 한다. 즉, ViewModel에 직접적인 변경사항이 발생한다.

기능 요구 사항 생성자 주입 - 자동 다음 문제점을 해결한다.

• ViewModel에서 참조하는 Repository가 정상적으로 주입되지 않는다.
• Repository를 참조하는 다른 객체가 생기면 주입 코드를 매번 만들어줘야 한다.
  • ViewModel에 수동으로 주입되고 있는 의존성들을 자동으로 주입되도록 바꿔본다.
  • 특정 ViewModel에서만이 아닌, 범용적으로 활용될 수 있는 자동 주입 로직을 작성한다. (MainViewModel, CartViewModel 모두 하나의 로직만 참조한다)
  • 100개의 ViewModel이 생긴다고 가정했을 때, 자동 주입 로직 100개가 생기는 것이 아니다. 하나의 자동 주입 로직을 재사용할 수 있어야 한다.
• 장바구니에 접근할 때마다 매번 CartRepository 인스턴스를 새로 만들고 있다.
• 여러 번 인스턴스화할 필요 없는 객체는 최초 한 번만 인스턴스화한다. (이 단계에서는 너무 깊게 생각하지 말고 싱글 오브젝트로 구현해도 된다.)

• [ ]TDD로 DI 구현
• [ ]Robolectric으로 기능 테스트
• [ ]ViewModel 테스트
• [ ]모든 도메인 로직, Repository 단위 테스트

1. 기존 object 형태의 container 구조변경 -> 여러가지 모듈 형태로 객체 생성후 최종 object 저장소로 등록할수 있도록 변경 사유: 테스트,혹은 여러가지 상황에 맞춰서 각각의 의존성 혹은 의존성 묶음을 교체해줄 수 있어야 DI툴의 강점을 살릴수 있다 판단.
2. 의존성 묶음인 Module을 override 할수 있도록 설정 및 qulifier 설정 사유: 위의 사유와 갖고 사용자의 편의성을 위해 묶음으로 교체할 수 있도록 기능제공
3. Koin의 declare 대체 함수 생성 -> 각각의 의존성을 특정한 상황에서 대체해서 사용할 수 있도록 기능제공 ex) 특정 기능들만 Mocking 해서 사용하여 테스트성을 올림 // 여기부터 시간이 남는다면 구현할 사항
4. 자동 등록 로직 -> 현재의 형태의 경우 의존성을 사용자가 무조건 미리 선행 등록을 해야함 이는 꽤나 불편하기 떄문에 패키지만 등록하면 그 패키지 내부를 리플렉션을 통해서 조사하여 자동등록 로직을 생성 but 수동 등록또한 여전히 존재 수동 등록을 한다면 자동 등록 로직을 덮어 쓰는 형태로 개발 ->(사용자가 다양한 생명주기를 이용하고 구분할 수 있도록)