[Swift] DI 와 Swinject

🧑🏻‍💻 소마 종찬 멘토님의 멘토링 팔로우업을 위해 정리한 글
(2022년에 작성한 게시글이었는데, 2023년에 조금 수정하고 보완했습니다.)

🍭 2023.04 추가 내용 : DI와 Swinject를 더 공부해서 Toy Project에 적용해봤습니다. 아래 코드를 참고하면 Swinject에 대한 이해도를 더 높이는 데 참고가 될 것 같습니다.

🔗 DI, Swinject 를 적용한 [소마 날씨 앱] : https://github.com/heyksw/Soma-WeatherApp

• Projects→App→Sources→DI
• Projects→App→Sources→Application→SceneDelegate.swift

이 두 군데를 살펴보면 됩니다.

---

DI (Dependency Injection)

면접에서 "DI가 뭐냐"고 하면 나는 이렇게 대답할 거다.

"Dependency Injection은 클래스 내부에서 필요한 객체의 인스턴스를, 클래스 내부에서 생성하는 것이 아니라 외부에서 생성한 뒤 이니셜라이저 또는 setter를 통해 내부로 주입받는 것입니다. 이 때 이니셜라이저의 타입은 프로토콜을 활용해서 내부에서는 프로토콜 메서드를 사용합니다."

Dependency Injection을 직역하면, 의존성 주입이다.
DI 는 "의존성" 을 클래스에 "주입" 시키는 것이고, "의존성 분리"의 조건을 만족해야 한다.

🧐 정확한 이해를 위해 다음 4가지 개념을 순서대로 정리했다.

1. 의존성
2. 주입
3. 의존성 분리
4. IOC Container

---

1. 의존성 (Dependency)

클래스 A, 클래스 B가 있고, 클래스 B의 값이 바뀔 때 클래스 A의 값도 함께 바뀌게 된다면 클래스A 는 B에게 의존성을 갖는다고 말한다.

LOL 을 예로 들어봤다. 플레이어가 있고, 플레이어는 AP 챔피언 중 가장 잘하는 챔피언 하나, AD 챔피언 중 가장 잘하는 챔피언 하나씩을 갖고 있다.

// AP 챔피언 클래스
class ApChamp {
    let name: String
    init(name: String) {
        self.name = name
    }
}

// AD 챔피언 클래스
class AdChamp {
    let name: String
    init(name: String) {
        self.name = name
    }
}

// 플레이어 클래스
class Player {
    let apMost: ApChamp
    let adMost: AdChamp

    // 클래스 내부에서 ApChamp, AdChamp 인스턴스를 생성하고 있다.
    init() {
        self.apMost = ApChamp(name: "아칼리")
        self.adMost = AdChamp(name: "요네")
    }
}

let ksw = Player()
print(ksw.apMost.name) // 아칼리
print(ksw.adMost.name) // 요네

만약 여기서 AdChamp 클래스의 name 타입을 이렇게 Int로 변경한다면,

// AD 챔피언 클래스
class AdChamp {
    let name: Int
    init(name: Int) {
        self.name = name
    }
}

ksw 의 init() 함수 내부에서 타입 에러가 나게된다. 즉, Player 클래스에도 영향을 끼친다. 이런 경우를 Player 클래스가 AdChamp 클래스를 의존한다 라고 표현한다.

여기서는 특히 Player 클래스의 init() 내부에서 ApChamp(), AdChamp() 인스턴스를 생성하고 있다는 걸 주목해야한다.

---

2. 주입 (Injection)

위의 Player 클래스 코드를 다음과 같이 수정할 수 있다.

class Player {
    let apMost: ApChamp
    let adMost: AdChamp

    // init 함수 수정
    init(apMost: ApChamp, adMost: AdChamp) {
        self.apMost = apMost
        self.adMost = adMost
    }
}

// 외부에서 클래스 내부에 값을 "주입"
let apChamp = ApChamp(name: "아칼리")
let adChamp = AdChamp(name: "요네")
let ksw = Player(apMost: apChamp, adMost: adChamp)

print(ksw.apMost.name) // 아칼리
print(ksw.adMost.name) // 요네

객체의 인스턴스를 외부에서 생성한 뒤 넣어주는 것을 주입이라고 한다.

현재 코드에선 AdChamp의 name이 Int 형으로 변경된다고 해도, Player 클래스의 init()에는 문제가 생기지 않게 된다. 그래도 AdChamp의 name value 가 바뀐다면, Player의 adMost 의 name value 도 바뀌므로 의존성은 남아있다. 쉽게 말해서, 클래스 A 내부에서 다른 클래스 B를 사용하고 있다면, A가 B를 의존한다고 생각할 수 있다.

여튼 이렇게 해서 "의존성"을 "주입"했다.

---

3. 의존성 분리

위의 코드까지 의존성 주입을 살펴봤다. 하지만 일반적으로 의존성을 주입시킨 것 만으로 DI 라고 부르지는 않는다.

의존성 분리의 조건을 만족시켜야 DI 라고 한다.
그리고 의존성 분리는 "의존 역전의 원칙"을 기반으로 분리를 실행한다.

SOLID 5원칙 중 Dependency Inversion Principle 을 의미한다.

🤓 DIP 원칙이란

• 의존 관계를 맺을 땐, 변화하기 쉬운 것보단 변화하기 어려운 것에 의존해야 한다는 원칙.
• 여기서 변화하기 어려운 것이란 추상 클래스나 인터페이스를 말하고 변화하기 쉬운 것은 구체화된 클래스를 의미.
• 따라서 DIP를 만족한다는 것은 구체적인 클래스가 아닌 인터페이스 또는 추상 클래스와 관계를 맺는다는 것을 의미.

따라서 Swift의 Protocol 을 사용해준다.

// ApChamp 와 AdChamp 이 공통으로 준수할 프로토콜.
// 프로토콜을 사용함으로써 의존 역전이 되었다.
protocol Champ: AnyObject {
    var name: String { get }
}

// Champ 프로토콜 채택
class ApChamp: Champ {
    let name: String
    init(name: String) {
        self.name = name
    }
}

// Champ 프로토콜 채택
class AdChamp: Champ  {
    let name: String
    init(name: String) {
        self.name = name
    }
}

class Player {
    let apMost: Champ
    let adMost: Champ

	// 프로토콜에 대고 주입받는다.
    init(apMost: Champ, adMost: Champ) {
        self.apMost = apMost
        self.adMost = adMost
    }
}

// 외부에서 클래스 내부에 값을 "주입"
let apChamp = ApChamp(name: "아칼리")
let adChamp = AdChamp(name: "요네")
let ksw = Player(apMost: apChamp, adMost: adChamp)

print(ksw.apMost.name) // 아칼리
print(ksw.adMost.name) // 요네

이렇게 프로토콜을 활용했을 때 장점은 다음과 같다.
ex) 프로토콜에서 champion 의 타입을 String 에서 Int 형으로 변경한다면 ?

→ ( Type 'ApChamp' does not conform to protocol 'Champ' )

모든 클래스들이 함께 에러를 가지게 된다. ApChamp, AdChamp 2개 클래스의 제어 주체가 모두 "프로토콜"에게 있게 된다. 프로토콜 하나만 잘 파악한다면, 그 프로토콜을 준수하는 모든 클래스를 제어하고 분석하기 쉬워지게 된다.

프로토콜을 사용하지 않은채 name의 타입을 String→Int 형으로 유지보수 하게 될 일이 생긴다면 모든 클래스를 일일히 확인해줘야 하는 번거로움이 생길 거다.

이런 과정이 잘 일어났을 때 클래스에서 프로토콜에게 의존의 방향이 역전 되었다고 한다.
= IOC (Inversion Of Control), 제어 반전 이라고도 한다.

그리고 DI를 했을 때 더 큰 장점은 이런 경우다.

ex) 갑자기 기획자가 Player의 apMost의 자리에 반드시 서포터 챔피언을 넣어달라고 요구한다. 근데 딱보니까 또 그 다음 버전에는 마법사 챔피언을 넣으라고 변덕을 부릴게 뻔하다.

// Support 챔피언 클래스
class SupportChamp: Champ {
    let name: String
    init(name: String) {
        self.name = name
    }
}

// MageChamp 챔피언 클래스
class MageChamp: Champ {
    let name: String
    init(name: String) {
        self.name = name
    }
}

class Player {
    let apMost: Champ
    let adMost: Champ

    init(apMost: Champ, adMost: Champ) {
        self.apMost = apMost
        self.adMost = adMost
    }
}

let apChamp = ApChamp(name: "아칼리")
let adChamp = AdChamp(name: "요네")
let supportChamp = SupportChamp(name: "카르마")
let mageChamp = MageChamp(name: "조이")

// * 여기만 바꿔주면 모든 수정 사항이 완료된다.
let ksw = Player(apMost: supportChamp, adMost: adChamp)
// let ksw = Player(apMost: mageChamp, adMost: adChamp)

print(ksw.apMost.name) // 카르마
print(ksw.adMost.name) // 요네

똑같이 Champ 프로토콜을 준수하는 Support, Mage 클래스를 외부에서 생성하고, 주입시키는 부분만 변경하면 모든 수정 사항이 완료된다. 이번 버전에는 supportChamp 주입하고, 바꾸라그러면 그때 그때 프로토콜을 준수하는 클래스로 교체만 해주면 된다. Player 클래스 내부의 어떤것도 수정할 필요가 없다.

현재 예시는 챔피언 클래스들이 갖는 프로퍼티가 name 뿐이지만, 이런 경우를 생각해보면 효과가 더 강력하다.

// Champ 가 갖는 요소가 훨씬 늘어날 경우
protocol Champ: AnyObject {
    var name: String { get }
    var HP: Int { get }
    var MP: Int { get }
    var 공격력: Int { get }
    var 방어력: Int { get }
    ...
    
    func normalSkill()
    func ultimateSkill()
    ...
}

Player 클래스 내부에서 프로토콜의 프로퍼티, 프로토콜의 메서드를 사용한다면 외부 객체 인스턴스를 교체해도 아무렇지 않게 잘 동작하게 된다.

이런 경우를 의존성이 낮아졌다. 결합도가 낮아졌다라고 표현한다.

---

4. IOC Container

여태 설명한 IOC, 의존 역전을 구현하는 프레임워크를 IOC Container 라고 한다.

제어권을 프레임워크가 가져가게 되는 것.
이를 위한 프레임워크로 Swinject 가 있다.

---

Swinject

Swinject : Swift 에서 DI (의존성 주입)을 위한 프레임워크. 객체 자체가 아니라 프레임워크에 의해 객체의 의존성이 주입되도록 한다.

In the pattern, Swinject helps your app split into loosely-coupled components, which can be developed, tested and maintained more easily.

→ DI 패턴에서 Swinject는 앱이 느슨하게 결합된 구성 요소로 분할될 수 있도록 도와주며, 이는 보다 쉽게 개발, 테스트 및 유지 관리할 수 있습니다.

pod 'Swinject'

---

Swinject 예제 수행

https://github.com/Swinject/Swinject
https://doodledevnote.tistory.com/30
공식 깃허브 예제를 수행해봤다.

---

1. AppDelegate.swift 에 Container 를 생성한다. 그리고 Container 에 프로토콜과 클래스를 등록한다.

• 의존성 주입은 클래스의 외부에서 한다. 따라서 ViewController 클래스의 외부인 AppDelegate 에 Swinject Container 를 선언해줬다.
  • register : Container 에 사용할 프로토콜 등록
  • resolve : 클래스 사용

import UIKit
import Swinject
import Foundation


protocol Animal {
    var name: String? { get }
}

class Cat: Animal {
    let name: String?
    
    init(name: String?) {
        self.name = name
    }
}


@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    let container: Container = {
        let container = Container()
  		// Cat 이라는 클래스에 Animal 프로토콜에게 제어권을 넘기는 동시에,
  		// 의존성을 주입한다.
        container.register(Animal.self) { _ in Cat(name: "Mimi") }
        
  		// ViewController 클래스를 등록한다.
        container.register(ViewController.self) { resolver in
            let controller = ViewController()
            controller.animal = resolver.resolve(Animal.self)
            return controller
        }
        return container
    }()
	
  ...

}

---

2. SceneDelegate.swift 에서 등록했던 ViewController 를 사용한다.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    let appDelegate = UIApplication.shared.delegate as! AppDelegate
    

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let scene = (scene as? UIWindowScene) else { return }
        
        self.window = UIWindow(windowScene: scene)
        self.window?.rootViewController = appDelegate.container.resolve(ViewController.self)
        self.window?.makeKeyAndVisible()
    }

---

3. ViewController.swift 에서 등록했던 Animal 을 사용한다.

import UIKit

class ViewController: UIViewController {
    var animal: Animal?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.
        print("Animal name is \(animal!.name!)")
    }
}

---

+ 같은 프로토콜을 준수하는 클래스가 여러 개일 경우

• Animal 프로토콜을 준수하는 Cat, Dog 클래스가 있을 때의 예시.

• AppDelegate.swift

import UIKit
import Swinject
import Foundation

protocol Animal {
    var name: String? { get }
    var cry: String? { get }
}

class Cat: Animal {
    let name: String?
    let cry: String?
    
    init(name: String?) {
        self.name = name
        self.cry = "Meow"
    }
}

class Dog: Animal {
    let name: String?
    let cry: String?
    
    init(name: String?) {
        self.name = name
        self.cry = "Bark"
    }
}


@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    let container: Container = {
        let container = Container()
        container.register(Cat.self) { _ in Cat(name: "Mimi")}
        container.register(Dog.self) { _ in Dog(name: "Popi")}
        
        container.register(ViewController.self) { resolver in
            let controller = ViewController()
            controller.cat = resolver.resolve(Cat.self)
            controller.dog = resolver.resolve(Dog.self)
            return controller
        }
        
        return container
    }()
...
}

• ViewController.swift

import UIKit

class ViewController: UIViewController {
    var cat: Cat?
    var dog: Dog?
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.
        print("Cat name is \(cat!.name!)")
        print(cat!.cry!)
        print("Dog name is \(dog!.name!)")
        print(dog!.cry!)
    }
}

---

🍩 2023.04 추가 내용

이 글을 게시한지 약 1년 뒤인 현재, DI / Swinject 에 대한 이해도가 더 높아졌고, 추가적인 내용을 작성하고 싶다.

가장 하고 싶은 말을 결론부터 이야기하면,

엄밀히 따지면, Swinject는 "DI 라이브러리"가 아니다.
정의만 놓고 얘기하면 "Service Locator"에 더 가깝다.

Swinject는 Service Locator 로써, DI 로써 모두 사용될 수 있다.

---

DI vs Service Locator

🔗 Service Locator 라고 말한 근거 : Dependency Injection in iOS with Swinject

위 링크의 말을 인용해서 가져오면 다음과 같다.

But Swinject is not a Dependecy Injection Framework. Sorry for the shock. Swinject is under the hood just a simple Service Locator and no real dependecy injection framework, what injects the dependecies already during the compile time. I know what you are thinking. You feel cheated. But hey: Swinject does generally a similar job as real DI framework does.

Swinject는 의존성 주입 프레임워크가 아닙니다. 충격을 줘서 미안합니다. Swinject는 단순한 서비스 로케이터일 뿐 실제 종속성 주입 프레임워크는 없으며 컴파일 시간 동안 이미 종속성을 주입합니다. 당신이 어떻게 생각하고 있는지 알고 있어요. 속았다고 느끼시는군요. 하지만 Swinject는 일반적으로 실제 DI 프레임워크와 유사한 작업을 수행합니다.

Service Locator : 누군가 필요로 하는 객체를 제공해주는 역할을 수행하는 객체를 말한다.

Swinject의 Container에 register하는 과정은 Service Locator에게 객체를 등록하는 과정이고, resolve해서 사용하는 것은 필요한 객체를 제공받아 사용하는 과정이다.

그래서 Swinject의 register / resolve 메서드만 단지 사용하는 것은 DI로써 사용한 것이 아니라 Service Locator로써 사용한 것이다.

프로토콜에 대고, 이니셜라이저나 setter를 통해서 객체 내부로 주입시키는 과정이 있어야만 DI로써 활용이 된 것이라고 할 수 있다.

🔗 Service Locator와 DI 개념을 자세히 설명한 글 → Service Locator vs DI

---

Assembly

Swinject에서 제공하는 Assembly는 비슷한 책임을 갖는 객체끼리 모아서 관리하고 등록할 수 있도록 돕는다. 예를들어 클린 아키텍처를 준수해 Domain 모듈, Data 모듈이 있는 상태라고 해보자.

[소마 날씨 앱]을 예로 들어보면, Domain 모듈에는 ViewModel에서 날씨 데이터를 가져올 수 있도록 돕는 UseCase 가 있고, Data 모듈에는 날씨 데이터를 서버에서 직접 가져올 WeatherDataSource 와 WeatherRepository 가 있다.

가장 상위 모듈인 App모듈에서 DI 주입을 해야하기 때문에, App모듈에 DomainAssembly.swift와 DataAssembly.swift를 정의한다.

// DomainAssembly.swift
import Domain
import Swinject

public struct DomainAssembly: Assembly {
    public func assemble(container: Container) {
        container.register(WeatherUseCase.self) { resolver in
            let repository = resolver.resolve(WeatherRepository.self)!
            return DefaultWeatherUseCase(repository: repository)
        }
    }

------------------------------------------------------------

// DataAssembly.swift
import Swinject
import Domain
import Data

public struct DataAssembly: Assembly {
    public func assemble(container: Container) {
        container.register(WeatherDataSource.self) { _ in
            return DefaultWeatherDataSource()
        }
        
        container.register(WeatherRepository.self) { resolver in
            let dataSource = resolver.resolve(WeatherDataSource.self)!
            return DefaultWeatherRepository(dataSource: dataSource)
        }
    }
}

그리고 이렇게 등록한 Assembly 들을 모아서 앱 실행 시작 시점에 함께 등록한다.

// SceneDelegate.swift 
import Swinject
import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?
    private let injector: Injector = DependencyInjector(container: Container())
    private var appCoordinator: DefaultAppCoordinator?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let scene = (scene as? UIWindowScene) else { return }
        let navigationController = UINavigationController()
        window = .init(windowScene: scene)
        window?.rootViewController = navigationController
        window?.makeKeyAndVisible()
        
        appCoordinator = DefaultAppCoordinator(dependency: .init(navigationController: navigationController, injector: injector))
        
        // * Service Locator 에 사용할 객체를 모아둔 Assembly 들을 모두 등록.
        injector.assemble([DataAssembly(),
                           DomainAssembly(),
                           HomeAssembly(),
                           ForecastAssembly(),
                           SearchAssembly()])
                           
        appCoordinator?.start()
    }
    ...
}

만약 서버에서 가져오던 Weather 데이터를 로컬에서 가져오도록 요구사항이 변경되었다고 가정해보자 (기능적으로 그럴일이 생길 것 같지는 않지만). 그렇다면 WeatherDataSource 프로토콜을 따르는 LocalWeatherDataSource를 커스텀해서 생성해내고, 위에서 본 DataAssembly 안의 코드를 다음과 같이 수정하면 된다.

public struct DataAssembly: Assembly {
    public func assemble(container: Container) {
        container.register(WeatherDataSource.self) { _ in
            // return DefaultWeatherDataSource()
            return LocalWeatherDataSource()
        }

이렇게 DI를 활용하면, 단 한 줄의 수정으로 추가적인 연쇄적인 수정없이 모든 작업을 끝낼 수 있게 된다.

---

Reference

https://github.com/Swinject
https://rma7.tistory.com/69
https://kkimin.tistory.com/47
https://medium.com/@jang.wangsu/di-dependency-injection-이란-1b12fdefec4f