[iOS] 의존성 주입(Dependency Injection) 개념과 예제 ( feat. Clean Architecture + MVVM)

Clean Architecture를 공부하면서 헷갈리는 개념이었던 '의존성 주입 (Dependency Injection)'에 대한 정리를 하려고 합니다.

다만, Clean Architecture에 대한 전 과정을 다루는 글이 아니니 이 점 참고부탁드립니다.

또한 완벽한 글이 아니다보니, 잘못된 내용이 있을 수 있으니 많은 지적 부탁드리겠습니다! :)

---

의존성(Dependency)이란? 

 

흔히, Clean Architecture의 가장 중요한 원칙을 설명할 때

 

"각 계층(Layer)은 서로 독립적이어야 하며, 한 계층의 변화가 다른 계층에 영향을 주어서는 안된다!"

 

라고 설명합니다.

 

여기서 말하는 '계층이 서로 독립적' 이라는 말은, 각 계층의 결합도를 최소화 하는것을 지향해야한다는 말 입니다.

하지만, iOS앱을 동작시키기 위해서는 각 계층간의 일정 수준의 상호 의존성(Dependency)이 필수적입니다.

 

Clean Architecture는 이런 '의존성(Dependency)'을 단방향으로  관리합니다.

Clean Architecture에서의 계층의 깊이를 보여준다.

그렇기 때문에, 위의 사진과 같은 의존성(Dependency)방향을 갖게 되는데,

여기서 말하는 '의존성(Dependency)' 의 의미는 "A가 B를 의존할 때, B의 변경사항이 A에도 영향을 미치게 된다" 라는 의미입니다.

 

의존성에 대해 간단한 코드를 예시로 들어보겠습니다.

class Calculator {
    func add(_ num1: Int, _ num2: Int) -> Int {
        return num1 + num2
    }
}

위와 같이 수학적 계산을 수행하는 Calculator라는 클래스를 갖는 앱이 있다고 가정해 보겠습니다. Calculator 클래스에는 두 개의 숫자를 더하는 add라는 메서드가 있습니다.

 

class MyViewController: UIViewController {
    let calculator = Calculator()
    
    func calculate() {
        let result = calculator.add(2, 3)
        print(result)
    }
}

이제 앱의 MyViewController에서 이 Calculator 클래스를 사용하고 싶다고 가정해 보겠습니다.
Calculator 클래스를 사용하려면 인스턴트를 생성 후, add 메서드를 호출해야 합니다.

 

그런데, Calculator의 코드가 아래와 같이 변경된다면 어떻게 될까요??

class Calculator {
    func sum(_ num1: Int, _ num2: Int) -> Int {
        return num1 + num2
    }
}

이렇게 된다면, MyViewController에서는 기존에 add 메서드를 호출해서 수행하던 동작을,

sum 메서드로 수정해야 이전의 동작이 가능하게 됩니다.

 

이처럼, A가 B를 의존하게 된다면, B의 정보가 변경되었을 때 A도 '적절한 행동을 취해야' 합니다.

 

---

'의존성 주입(Dependency Injection)' 이란??

 

위에서 설명한 단방향 의존성을 Clean Architecture에 적용하게 된다면 아래의 사진과 같은 관계가 됩니다.

Presentation과 Data는 같은 Level에 있는 계층들이고, Domain은 보다 깊은 Level에 있는 계층이다.

같은 Level에 있는 Persentation, Data는 Domain을 의존하게 됩니다.

즉, Domain은 Presentation과 Data를 의존하면 안됩니다.

 

 

자, 그런데 우리는 Clean Architecture에서 계층간의 결합도는 최대한 줄이는게 좋다고 했습니다.

그리고 이것을 위해 사용하는 것이 '의존성 주입 (Dependency Injection)' 입니다!

'의존성을 주입한다'의 뜻은, '외부'에서 의존성을 부여한다는 의미 입니다!

 

계층간의 결합도를 줄이기 위해서는, 의존성을 낮춰야 하는데 오히려 의존성을 더한다,,,,? 

 

라고 생각 할 수 있는데, 여기서 중요한건 '외부'에서 의존성을 부여한다는 것입니다.

코드를 예로들어 설명 해보겠습니다.

 

 

우리가 흔하게 생각하는 '의존성'을 갖는 관계는 아래의 코드와 같이,

Class 내부에서 다른 클래스의 인스턴트를 생성하는 것 입니다.

class Calculator {
    func add(_ num1: Int, _ num2: Int) -> Int {
        return num1 + num2
    }
}

class MyViewController: UIViewController {
    let calculator = Calculator()
    
    func calculate() {
        let result = calculator.add(2, 3)
        print(result)
    }
}

// 이 코드는, MyViewController 내부에서 Calculator의 인스턴트를 생성하고 있습니다.
// 그렇기 때문에, MyViewController -> Calculator의 의존성 관계를 갖습니다.

 

 

그렇다면, 이번에는 의존성 주입 (Dependency Injection)을 사용해보겠습니다.

 

이러한 의존성 주입에는 

1. 생성자 주입

2. setter 주입

3. 인터페이스 주입(의존성 분리)

 

이렇게 3가지의 방식이 있는데, Clean Architecture에서는 의존성 분리를 채택하고 있습니다.

그리고 이를 위해선 '의존성 역전 원칙 (Dependency Inversion Principle)'에 대해 먼저 알아야 합니다.

 

이 원칙에는 2가지의 규칙이 있는데, 

• 상위 계층은 하위 계층에 의존하면 안된다. 두 계층 모두 추상화에 의존해야한다
• [ 추상화 -> 세부사항 ]의 의존관계가 아닌 [ 세부사항 -> 추상화 ]의 의존관계를 가져야한다.

그리고 이를 위해서 Swift 에서는 protocol을 사용합니다. 

protocol Calculatable {
    func add(_ num1: Int, _ num2: Int) -> Int
}

class Calculator: Calculatable {
    func add(_ num1: Int, _ num2: Int) -> Int {
        return num1 + num2
    }
}

class MyViewController: UIViewController {
    let calculator: Calculatable = Calculator()
    
    func calculate() {
        let result = calculator.add(2, 3)
        print(result)
    }
}

// 이 코드는 Calculatable이라는 외부protocol을 통해서 의존성이 만들어지고 있습니다.
// 즉, 실제 의존성의 방향은 MyViewController -> Calculatable <- Calculator

차이점이 보이시나요??

기존의 코드는 MyViewController -> Caculator 의 방향으로 의존성을 가지고 있지만,

위의 코드는 외부 protocol인 Calculatable을 사용하여 의존성을 주입하였습니다.

 

그 결과 MyViewController -> Calculatable <- Calculator 이라는 의존성 관계가 생성됩니다.

 

이러한 의존성 주입 (Dependency Injection)은 실제 계층간의 결합도를 낮추는 효과를 가져옵니다.

왜냐하면, protocol 이라는 외부의 껍데기를 통해서 서로 느슨하게 연결되어 있기 때문이죠!!

또한, 계층간의 결합도가 낮기 때문에 Unit단위의 Test가 용이하다는 장점도 있습니다!

 

 

 

그렇다면, 우리가 공부하고 있는 Clean Architecture에 적용해서 생각 해 보겠습니다

 

 

 

---

Clean Architecture + MVVM 에서의 '의존성 주입(Dependency Injection)'

 

 

우리가 알고있는 Clean Architecture에서는

Domain에는 앱의 핵심 기능과 같은 비지니스로직을 담당하는 UseCase가 들어있고,

Data에는 RestAPI 처리나, 데이터 캐싱 같은 네트워킹 로직들을 갖는 Repository가 들어가게 됩니다.

 

그리고 UseCase에서 비지니스로직을 처리하기 위해서는 이러한 로직 처리를 위한 데이터를 서버에서 가져 올

Repository의 Networking 작업이 선행되어야 합니다.

 

이것이 의미하는 바는, UseCase는 Repository를 의존해야 한다는 뜻 입니다.

하지만, UseCase는 Repository보다 더 하위 계층이기 때문에 직접 소유할 수 없습니다.

 

그렇기 때문에, Domain 계층에 protocol을 두어서 '의존성 역전 원칙'을 지키는 '의존성 주입'을 진행하게됩니다.

 

protocol을 Domain Layer에 선언하고, protocol의 내부 구현을 Data Layer에서 진행을 하게 된다면

 

Domain [ UseCase → Protocol ] ← Data[ Repository ] 이와 같은 형태를 띄게 됩니다.

 

이를 통해서,

1) Domain 계층과 Data계층간의 결합도는 낮아지고

2) Repository의 변화가 UseCase에 직접적인 영향을 주지 않게 됩니다!

 

 

이와 비슷하게, Presenter -> Domain의 관계에서도 protocol을 사용한 '의존성 주입'이 이뤄지게 됩니다.

하지만, Domain과 Data 사이의 '의존성 주입'과는 뭔가 목적성이 다르다고 느껴지시죠??

 

이처럼, Clean Architecture에서는

Domain 계층과 Data 계층의 관계에서 처럼 

1) 의존성의 방향을 제어하기 위해서 

Domain 계층과 Presenter 계층의 관계에서 처럼

2) 각 계층의 결합도를 느슨하게 하기 위해서

 

즉, 다양한 목적성을 위해 동일하게 '의존성 역전 원칙'을 따르는 '의존성 주입'기술을 사용합니다!