Swinject를 사용한 iOS 의존성 주입

배경

Inversion Of Control (제어의 역전)

개발자가 작성한 객체나 메서드의 제어를 개발자가 아니라 외부에 위임하는 설계 원칙

객체 지향 프로그래밍에서는 코드에서 의존성을 제거해야한다.

 

의존성 주입

하나의 객체가 다른 객체에게 의존성을 제공하는 기술

의존성 주입은 IOC를 달성하는 방법 중 하나다.

 

이것의 이면에 있는 아이디어는 별도의 개체가 필요한 의존성을 생성하고 클라이언트에 전달하도록 하는 것이다.

 

이점

1. 테스트 하기 편하다.

2. 의존성 역전 원칙(DIP)를 지킬 수 있다.

 

DI Container

객체를 인스턴스화하고 구성하는 방법을 알고있는 객체

DI Container는 의존성 주입을 구현하기 위한 디자인 패턴이다.

복잡한 의존성을 해결하기 위해 사용한다.

 

Swinject

Swift 앱을 위한 경량 의존성 주입 프레임워크

Swinject를 통해 앱을 느슨하게 결합된 Component로 분할하여 유지보수 및 테스트가 쉽게 해준다.

 

예제를 통해 살펴보기

우리는 'NetworkManager' 클래스의 loadData 메서드를 테스트 해야 한다.

이 메서드는 URLSession으로 서버에서 데이터를 가져오고 모델의 response를 디코딩한다.

그러나 인터넷에 연결될 때까지는 이 방법을 테스트할 수 없다.

결국 이것은 좋은 방법이 아니다.

이런 상황일 때, 모의 데이터를 반환하는 모의 URLSession을 주입하여 서버를 어떻게든 모의처리하면 어떨까?

 

위에서 말했듯이 모의 데이터를 반환하고 모의서버 역할을 해줄 MockUrlSession과 MockUrlSessionDataTask 클래스를 만들었다.

우리는 urlSession 속성을 만들고 생성자로 주입했다.

이제 NetworkManager는 urlSession을 생성자를 통해 주입하므로 UrlSession을 만드는 것에 대한 책임이 없다.

(이전에는 NetworkManager가 UrlSession이 만들어지는 것에 대한 책임이 있었다.

인터넷이 잘되서 UrlSession이 잘 만들어져야만 테스트할 수 있었음)

아래 절차를 따르면서 의존성을 주입하였다.

1.  종속/외부 객체를 생성하기 위해 클래스의 불필요한 책임을 하나 제거했다. (목표는 단일책임원칙을 지키는 것)
2. Intiializer Injection 패턴을 사용하여 의존성주입을 구현했다.

 

이제 테스트하기 쉬워진 것을 볼 수 있다.

 

Swinject가 필요한 이유

DI Container는 의존성 주입을 구현하기 위한 디자이너 패턴이다.

대부분의 경우 의존성 주입의 이점을 얻기 위해 꼭 DI Container가 필요한 건 아니다.

그러나 의존성이 많은 다양한 객체를 관리해야 하는 경우 DI Container가 정말 유용할 수 있다.

Swinject는 Swift에서 DI Container를 구현한 것이다.

 

위의 그림에서 볼 수 있듯 ClientA와 ClientB 모두 DataFetcher에 의존하고 있다.

생성자를 통해 의존성을 주입을 하고있다.

이런 상황에서 코드를 보며 무엇을 알 수 있을까?

• ClientA와 ClientB에 중복 코드가 있다.
• 모든 의존성을 생성하여 객체를 관리해주는 곳이 있었으면 좋겠다..

여기서 DI Container가 도움이 될 것이다.

DI Container는 아래와 같이 타입 의존성을 관리한다.

1. 의존성과 함께 resolve되어야 하는 타입들을 등록한다.
2. DI Container를 사용하여 의존성이 DI Container에 의해 자동으로 resolve되는 타입의 인스턴스를 가져온다.

Swinject로 DI Container를 구현하기 전에 몇가지 용어를 정의해보자.

 

용어

• Service : 의존 타입에 대한 인터페이스를 정의하는 프로토콜
• Component : 서비스를 구현하는 실제 타입
• Factory : Component/의존 객체를 인스턴스화하는 함수 또는 클로저 (예제에서는 DataFetcher)
• Container : Component 인스턴스들의 집합 (의존 객체가 register되고 resolve되는 DI Container)

DI Container 만들기

의존성을 한 곳에서 관리하기 위해 다음과 같은 절차를 거쳤다.

1. 생성자를 사용해서 Container의 인스턴스를 얻는다. (Container는 싱글톤 아님, 따라서 매번 새 인스턴스 생성)
2. DI Container에 DataFetcher를 등록하고 Factory에서 의존성을 resolve 또는 생성하는 방법을 register한다.
3. 이제 클라이언트가 인스턴스를 원할 때 resolve 메서드를 호출한다.
   (DI Container는 이 타입의 Service가 이미 등록되어 있는 지 확인한다.)

만약 Service가 이미 등록된 경우 Factory 클로저를 실행한다.

의존성을 resolve한 후, 모든 의존 객체가 채워진 새로운 DataFetcher 객체를 반환한다.

(register할 때와 resolve할 때 메모리주소가 같은 것을 볼 수 있다.)

 

Fetcher 프로토콜 register/resolve

이제 Fetcher.self를 Service 프로토콜로 등록하고 DI Container를 사용하여 resolve한다.

 

Named Registration

위 사진처럼 동일한 Fetcher 프로토콜을 2번 resolve해주고 있다.

동일한 Service 타입 프로토콜을 register하는 방법이 필요할 수 있다.

이런 경우 DI Container의 Named Registration을 사용한다.

위에서 보는 것처럼 resolve 메서드 내부의 name 파라미터를 이용해서 등록할 수 있다.

 

argument 전달

DI Container에 의해 resolve되어야 하는 객체는 동적 구성이 필요하다.

이때 DI Container의 argument를 사용한 등록이 중요해진다.

register 메서드에 전달되는 Factory 클로저는 Service가 resolve 될 때 전달되는 argument를 받을 수 있다.

argument는 위에서 보는 것처럼 매개변수로 지정할 수 있다.

참고로 Swinject에서는 최대 9개의 argument를 전달할 수 있다.

 

Container 싱글톤 만들고 써보기

이제 Container 클래스의 확장을 이용해 sharedContainer 속성을 생성했다.

이 속성은 모든 등록이 완료될 때까지 Container의 싱글톤 객체를 반환한다.

 

또한 register 메서드의 팩토리 클로저에서 DataFetcher의 인스턴스를 생성하는 방법을 Container에 알리고 있다.

 

Client들은 클래스에서 resolve 메서드를 호출하고, DataFetcher의 인스턴스를 생성하도록 지시한다.

그러면 컨테이너는 Factory 메서드를 실행하고, 의존성을 resolve 한 후 DataFetcher의 인스턴스를 반환한다.

앞서 언급한 것처럼 DI Container의 이점 중 하나는 "복잡한 의존성"을 해결하는 것이다.

또한, 객체 인스턴스를 한 곳에서 생성하고 관리하게 해주는 역할을 한다.

 

객체 스코프 (Object Scope)

DI Container에서 제공되는 인스턴스가 시스템 내에서 고유되는 방식을 결정하는 옵션. Swinject에서는 네 가지 지원

DataFetcher.self에 대해 resolve를 호출할 때 마다 항상 새로운 인스턴스가 반환된다. (메모리 주소가 다름)

하지만 동일한 인스턴스를 원하는 경우 어떻게 해야할까?

이 때 객체 스코프가 사용된다.

 

그래프 스코프 (기본 스코프)

resolve를 호출할 때마다 새로운 인스턴스를 생성하지만 그래프를 resolve하는 동안 인스턴스를 공유한다.

Class A는 B와 C에 의존하고, Class C는 B에 의존한다.

 

A를 resolve할 때 resolver에 의해 아래의 동작이 수행된다.

1. A의 의존성인 B와 C를 식별한다.
2. B를 resolve : 먼저, B의 의존성을 확인하고 발견하지 못하면 새로운 B 인스턴스(0x0000600002aa69d0)를 생성하고 그래프가 아직 해결되지 않았으므로 공유 컨테이너에 저장한다.
3. C를 resolve : 먼저, C에 의존하고 있는 B를 확인한다. 그런 다음 공유 컨테이너를 확인하여 주소가 (0x0000600002aa69d0)인 B 인스턴스를 찾는다. 이 B 인스턴스를 C 속성에 할당하고 C 객체를 생성한다.
4. 이제 A는 모든 의존성을 해결했으므로 A 객체를 반환한다. 그래프가 해결되었으므로 공유 컨테이너가 삭제된다.
5. 이제 A 및 C 클래스의 B 주소가 동일하다.

 

Container 스코프

싱글톤으로도 알려진 스코프. 한번 객체가 resolve되면 응용 프로그램이 종료될 때까지 모든 resolve메서드에 대해 인스턴스를 공유한다.

Container 스코프

Transient 스코프

항상 새로운 객체를 반환하는 스코프. (컨테이너에서 제공하는 인스턴스는 공유되지 않는다.)

인스턴스들의 메모리 주소가 다르게 출력되는 것을 볼 수 있다.

 

Custom 스코프

사용자 정의 스코프. (.custom 내에서의 인스턴스는 .container 스코프와 동일한 방식으로 공유되지만 필요에 따라 폐기 가능)

1. 객체 스코프를 확장해서 custom 속성을 추가하고 저장 타입의 스코프를 PermanentStorage로 만들었다.
(저장된 인스턴스는 명시적으로 폐기 될 때까지 유지)

 

2. UserSession을 custom 스코프로 등록했다.

3. loginUser 메서드에서 UserSession의 인스턴스를 가져오고 토큰을 설정했다.

4. 이제 UserSession을 resolve할 때마다 콘솔에 표시된 것 처럼 동일한 인스턴스를 얻을 수 있다.

5. logOut에서는 이 스코프를 폐기해서 앞으로 UserSession을 resolve하면 새로운 인스턴스를 얻게 된다.

 

몇 가지 포인트

• Registration Keys : Container에는 Service를 위해 Compoent를 등록할 때 내부적으로 생성된 키가 사용된다. Container는 Service 의존성을 resolve하려고할 때 이 키를 사용한다.
• Value Types injections : 이전 예제에서는 클래스를 사용했지만, 구조체(Struct)도 resolve할 수 있다. (Value 타입에는 약한 스코프(weak scope)를 사용할 수 없다.)

 

---

Ref

https://ali-akhtar.medium.com/ios-dependency-injection-using-swinject-9c4ceff99e41