의존성

class B {

    func hi() {
        print("B가 인사 중 👋🏻")
    }
}

class C {

    func hi() {
        print("C가 인사 중 👋🏻")
    } 
}

class A {

    let b: B = B() // A가 B에 의존한다 ✅

    func sayHello() {
        b.hi()
    }
}

let a = A()
a.sayHello() // B가 인사 중 👋🏻

• A가 B에 의존한다.
  • 이때 B에 변경사항이 있으면, A도 변한다.
    • hi() 메서드 이름을 hello() 로 수정 시, A에 따로 수정이 필요하다.
  • A→B로 표현한다.
• 의존성: 서로 다른 객체 사이에 의존 관계가 존재한다.
• 프로젝트에 적용한다면, NetworkManager 을 이런 방식으로 바로 호출하는 경우가 허다함. (나…)
• 화살표
  

의존성 주입

주입

• 생각보다 익숙한 개념이다.

  class A {
  	 let b: B
  	 
  	 init(b: B) {
  		 self.b = b
  	 }
  }
  
  let b = B()
  let a = A(b: b)

• 생성자를 통해 외부에서 값을 할당해 주는 것
• 하지만 주입만 한다고 해서, 제대로 된 의존성 주입이 되는 것은 아니다.

의존성 주입

따라서 제대로 DI를 하려면, 의존성을 분리시켜야 한다.

📌 DIP(의존성 역전 원칙): 상위 모듈과 하위 모듈은 추상화된 것에 의존해야 한다

의존성을 분리하기 위해서는 SOLID 원칙 중 하나인 위의 개념을 적용시켜야 한다.
공통의 속성이나 기능을 묶어 하나의 일반적인 개념으로 만드는 것을 추상화라고 한다.

쉽게 생각하면 공통된 성질을 추출하여 하나의 묶음으로 상위 클래스를 선정하는 것이다.

그리고 Swift의 주된 추상화 방법은 protocol을 사용하는 것

의존성 주입을 해 보자.

protocol 모듈화 {
    func hi()
}

위의 예제를 통해 protocol을 만들었다.

class B: 모듈화 {

    func hi() {
        print("B가 인사 중 👋🏻")
    }
}

class C: 모듈화 {

    func hi() {
        print("C가 인사 중")
    }
}

class A {
    let b: 모듈화

    init(b: 모듈화) {
        self.b = b
    }

    func sayHello() {
        b.hi()
    }
}

let a = A(b: B())
a.sayHello() // B가 인사 중 👋🏻

• 주입할 객체는 해당 프로토콜을 채택한다.
• 주입 시에는 protocol 타입으로 주입한다.

DI 장점

이를 통해

1. 확장성 증가

   class C: 모듈화 {
   
       func hi() {
           print("C가 인사 중")
       }
   }
   
   let a = A(b: C())

   A 클래스 내부에서 객체를 프로토콜 타입으로 지정했기 때문에, 해당 프로토콜을 채택한 객체라면 쉽게 교체 가능하다

   
   

2. DIP(의존 역전 원칙) 원칙을 따름
   
   B를 봤을 때, 화살표의 방향이 역전되었음을 알 수 있다.

DI 단점

• 결국 추상화된 모듈을 하나 더 만드는 것이므로, 그만큼 cost가 든다.

• 종속성 주입은 컴파일이 아닌 런타임 때 일어나기 때문에, 컴파일할 때는 의존성 주입에 대한 에러를 잡기 어려움.

  컴파일 타임 - 프로그래머가 작성한 소스코드를 컴퓨터가 이해하는 기계어로 변환하는 시간
  런타임 - 컴파일 타임 후에 프로그램이 실행되는 시간

Swift에서는 DI를 도와주는 여러 라이브러리들이 존재한다고 한다.
검색해 보니 Swinject가 가장 유명한 듯함.
일단 익숙해지고 써보려 한다.