DIContainer를 적용하면서 리팩토링이 마무리 되었지만, 아직 남아있는 호기심(?) 때문에 제가 작성한 코드를 들여다보고, 여러 레퍼런스도 찾아보고, Swinject 코드를 뜯어보면서 DIContainer에 대해 더 공부를 하고 있었습니다. 코드를 살펴보던 중 한 가지 궁금한 점이 생겼습니다. 제가 구현한 DIContainer는 의존성을 저장하기 위해 딕셔너리를 사용하고 있는데, Swift의 딕셔너리는 강한 참조로 유지합니다. 그렇다면 이 구조에서 컨테이너가 객체를 강하게 참조하는 것은 단순한 구현상의 선택일까요, 아니면 DI 설계 관점에서 의도된 동작일까요? 이 궁금함을 해결하기 위해 나름의 연구를 진행하게 되었습니다. 그래서 이번 글에서는 DIContainer 내부에서 발생하는 강한 참조를 중심..

ObjectScope이전 버전에서 저는 팩토리 클로저를 저장하는 방식으로 객체 생성 시점을 lazy~하게 resolve 시점으로 미뤘습니다. 하지만 문제가 하나 있었죠? let service1 = container.resolve(ReadingJourneyServicing.self)let service2 = container.resolve(ReadingJourneyServicing.self)// service1 !== service2resolve를 호출할 때마다 팩토리 클로저가 실행되어 매번 새로운 인스턴스가 만들어집니다.ReadingJourneyService처럼 여러 Builder가 공유해야 하는 서비스라면 데이터가 공유되지 않는 문제로 이어집니다. 실제 코드로 확인해 보아도, 두 객체의 메모리 주..

자 이제 구현한 DIContainer를 적용해 봅시다.목표를 다시 한 번 짚어봅시다.핵심은 간단합니다. 1. SceneDelegate는 resolve만 한다.2. Builder와 Service 생성은 container가 한다. 먼저 목표 구조를 생각해 봅시다. 제가 생각하는 가장 베스트는 아래와 같습니다.let container = DIContainer()let coordinator = container.resolve(AppCoordinator.self)coordinator.start()왜 이런 구조를 목표로 하고 있을까요? 1. SceneDelegate의 책임 최소화기존 구조에서는 SceneDelegate가 아래와 같은 역할을 모두 수행하고 있습니다.1. 서비스 생성2. Builder 생성3. Buil..