[iOS] Dependency Injection (의존성 주입) 이란?

1차 수정: 21.08.11
2차 수정: 21.09.27

안녕하세요 🐶
이번 시간에는 흔히 DI 라고 불리는 의존성 주입에 대하여 알아보겠습니다.
그럼 하나씩 알아볼게요!!!🔥🔥🔥

---

Injection

Dependency Injection means giving an objects its instance variable.
Really. That's it - James Shore

위 문장은 의존성 주입에 대해 가장 간단하고 명료하게 설명하고 있습니다.
이 개념을 설명할 때 자주 등장하는 인용문인 것 같아요!

Dependency Injection 은
A 라는 객체의 속성을 A가 아닌 다른 객체가 초기화해주는 것을 의미합니다.
왜 스스로 하지 않고 다른 객체를 통해서 초기화해야만 할까요??

결론부터 살펴보자면:
객체간 결합을 느슨하게 만들 수 있습니다.
위와 같은 의미지만, 좀 더 변경에 유연해지고 재사용이 가능한 코드가 될 수 있습니다.
주입받는 속성의 타입을 프로토콜로 만들어주면 테스트가 용이해지고, 의도가 명확한 코드를 작성하는데 도움이 됩니다.

우선 단어들의 정의부터 한번 살펴보겠습니다!!!

---

의존성?

객체 지향의 협력은 연속된 요청과 응답으로 구성되어 있다.

DI 의 D 는 Dependency, 즉 의존성을 가리킵니다.
의존성은 UML 클래스 다이어그램의 의존관계를 생각하면 이해하기 쉽습니다.

의존 관계에 대해 검색해보세요!

의존 관계는 한 클래스가 다른 클래스에서 제공하는 기능을 사용할 때 발생합니다.
예를 들어 A 라는 클래스가 연산에 B라는 클래스의 기능 (메서드) 를 사용한다면
A는 B에 의존관계가 있으며, 의존성이 생겼다고 볼 수 있습니다.

class A { func hasDependency() -> Int { return B.default.someFunction() // B 클래스의 싱글톤을 사용하였다고 가정하였습니다. } // A 클래스의 메서드의 반환값이 B 클래스 메서드의 반환값에 따라 바뀌므로 의존한다고 볼 수 있습니다. }

잠깐, 글쓴이는 아직 궁금한 점이 있습니다 🤔

>> 이 부분은 의존성 주입을 처음 공부하시는 분이면 넘어가도 좋을 것 같습니다. <<

위 코드에는 소프트웨어 공학의 클래스 다이어그램에서 표현되는

'의존 관계 (dependency) '가 정확하게 맞습니다.

사용하는 객체의 참조를 직접 소유하고 있지 않고,

메서드 내부에서와 같이 짧은 시간동안만 관계가 유지되기 때문입니다.

출처 : 어떤 도서를 공부한 독자의 네이버 블로그

하지만 의존성 주입에서는 속성 주입이나 생성자 주입을 사용하기 위해 변수나 상수에 참조를 저장합니다.

이런 객체 간의 관계는 클래스 다이어그램에서는 '연관 관계 (association)' 로 표현하거든요??

그래서 왜 연관성 주입이 아니라 의존성 주입인지 한동안 고민했었는데,

그냥 연관성이라는 단어를

클래스 다이어그램이라는 영역에서만 사용하기로한 용어로 생각하기로 하였습니다.

(결론 : 나름 해결함)

---

왜 의존성 주입이 필요한가?

의존성은 한 클래스가 다른 클래스의 기능을 사용할 때 발생한다고 위에서 말씀드렸는데요.

그러면 다른 클래스의 기능을 사용할 수 있는 방법은 무엇이 있을까요?

아래에서는 A 클래스가 B 클래스에 의존성이 생기는 경우로 가정해서 글을 쓰겠습니다.

가장 대표적인 세 가지를 나열해보자면

1. B 클래스의 싱글톤을 이용한다

2. 인스턴스 변수 혹은 상수로 B 클래스의 참조를 가진다

3. 메서드의 전달인자로 참조를 전달받는다

위 세가지 경우를 하나씩 살펴보려고 합니다🔎

이 때, 단순히 의존성이 생기는 것과 의존성을 주입하는 것은 구별해야 한다는점을 기억해주세요!

---

1. B 클래스의 싱글톤을 이용할 때 의존성이 생긴다.

class A { func hasDependency() -> Int { return B.default.func() // B 클래스의 싱글톤을 사용하였다고 가정하였습니다. } }

우선 싱글톤을 이용하는 방법은 의존성 주입에 포함되지 않습니다.
다른 클래스의 기능을 사용하기 가장 편한 방법이지만 큰 단점이 있습니다.
바로 Testable 하지 않다는 것입니다.
A를 기능을 Test 하려면 제대로 초기화된 B가 필수적으로 필요하기 때문입니다.
소프트웨어 공학에서는 항상 설계할 때 결합도를 낮추고, 응집도를 높이라는 말을 자주 보게 되는데요.
이렇듯 싱글톤 오브젝트를 사용하게 되면 코드의 결합도가 높아지고, 테스트하기 어려운 코드가 됩니다.
:: 이런 이유 때문에 싱글톤을 안티패턴이라고 표현하는 분들도 있습니다. 항상 Controversy 한 Topic 인것 같습니다.

또한 A 클래스가 의존성이 있는지 확인하려면
A의 모든 기능을 훑어봐야하기 때문에 유지 보수도 힘들겠네요!!

---

2. 인스턴스 변수 혹은 상수로 B 클래스의 참조를 가진다.

2번 방법은 다시 두 가지로 나뉠 수 있습니다.

2-1. A 클래스가 B 클래스 인스턴스를 직접 생성한다

class A { private let b = B() }

A 클래스 가 B 클래스의 생명주기를 직접 관리하게 되는 패턴입니다.
그런데 A 가 B 의 초기화 방법 까지 알 필요가 있을까요?
단일 책임 원칙과 관심사의 분리에 어긋나는 설계 방법이라고 생각합니다.
아래에 더 좋은 방법이 있습니다.

---

2-2. B 클래스를 직접 생성하지 않고, 외부에서 전달해준다

그런데 2-2 방법에는 또 두가지 방법이 있습니다.
그리고 그 두 가지 방법을 의존성 주입이라고 가리킵니다.

2-2-1. 초기화 시점에 전달한다

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

이 방법을 사용하면 초기화 시점에 A 클래스가 어떤 클래스에 의존성이 있는지 명확하게 알 수 있는 장점이 있습니다.
또한 B 클래스 오브젝트 생성에 관여하지 않으니, 결합도가 줄어들고 결과적으로 SRP 에 더 부합하게 됩니다.

부가적인 장점으로는 초기화 시점에 전달하므로 속성이 항상 존재함을 보장할 수 있고,
( 초기화 실패시 인스턴스는 생성되지 않으므로 )
그 이유 때문에 Optional 로 래핑하지 않아도 된다는 점이 있습니다.

프로토콜 두두둥장 :

그런데 여기에 스위프트의 프로토콜 지향 개념을 추가하면, 더 멋지게 동작하는 코드를 만들 수 있습니다.

protocol Bable { func test() -> Int } class A { private let b: Bable init(b: Bable) { self.b = b } }

위 코드에서처럼 인스턴스 상수를 B 타입으로 선언하는 대신,
B 에게서 필요한 기능들만을 요구사항으로 갖는 Babel 프로토콜 타입으로 받으면, 구현이 훨씬 더 자유로워집니다.

요구사항만 충족하는 타입이라면 어떤 클래스도 넣을 수 있게 되니까요.

또한 B의 모든 기능을 사용하는것이 아니라 프로토콜을 통해 제한된 기능만 사용할 수 있으므로,
불필요한 코드 확장이 없어집니다.

마지막으로 테스트 측면에서
Bable 프로토콜을 채택한 임의의 Mock 객체로 대체가 수월하므로 Testable 해집니다.

:: 프로토콜 작명에서 보통 속성을 사용하면 -Type, 기능을 사용하면 -able 을 접미어로 붙이는 것같아서 B-able 로 작명하였습니다.

---

2-2-2 초기화 이후, A 클래스 외부에서 속성에 접근하여 전달한다.

 override func prepare(for segue: UIStoryboardSegue, sender: Any?) { guard let vc = segue.destination else { return } /* 인스턴스 vc 의 속성 b 에 B 인스턴스를 주입 */ vc.b = B() }

iOS 개발에서는 2-2-2 방법을 사용해야만 의존성 주입이 가능한 경우가 있습니다

바로 Storyboard, xib 로 앱 UI 를 구성할 때인데요.

Storyboard 로 앱 UI 를 구성하면, 커스텀 이니셜라이저를 사용할 수 없습니다.

왜냐하면 UI 를 구성할 때 필연적으로 UIKit 의 UIView 서브클래스를 사용해야 하는데,
생성자를 통한 의존성 주입( 방법 2-2-1) 을 위해 커스텀 이니셜라이저를 만들경우
required init(coder:) 를 직접 구현해야 합니다. ( 수퍼 클래스의 생성자 자동 상속이 취소되기 때문입니다.)
:: 이 부분은 NSCoding, Swift 의 상속, Protocol 개념을 제대로 알고 있어야 이해가 가능합니다.

init(coder:) 는 Xcode 가 Storyboard 나 xib 파일을 언아카이빙할때 사용하게 되는 생성자입니다.
직접 구현할 수는 있지만, 호출하여 사용할 수는 없습니다.

따라서 이 방법을 사용하면 초기화 시점 이후에 속성을 넣어주어야하기 때문에, 속성 타입을 옵셔널로 선언합니다.

또한 같은 이유로 상수가 아닌 변수로 지정해주어야 한다는 번거로움이 있습니다.

결론적으로 이 방법은 Storyboard 방식으로 UI를 구성하는 경우, 의존성 주입하기 위해 사용할 수 있는 방법입니다.


init(coder:) 에 대해 궁금하다면? 👉🏻 [iOS] init(coder:) 란?
아카이빙, 언아카이빙에 대해 궁금하다면? 👉🏻[iOS] NSCoding 이란? (feat. 인코딩, 디코딩, 아카이빙)

---

3. 메서드의 전달인자로 참조를 전달받는다.

class A { var someValue: Int func useB(b: B) { self.someValue = b.getValue() } } let a = A() let b = B() a.useB(b: b)

이 방법의 경우
메서드를 사용하는 시점만 일시적으로 의존관계가 생기는 특징이 있습니다.

---

그래서 우리는 무엇을 얻을 수 있는가

이 결론에 도달하려고 정말 길게도 글을 썼네요...ㅎㅎㅎㅎ

의존성 주입으로 우리는:

책임이 좀 더 명확해진 클래스를 얻을 수 있습니다.
어떤 의존 관계와 요구사항이 있는지 수월하게 확인할 수 있습니다.

Testable 한 클래스를 얻게 됩니다.
Protocol type으로 받을 시 쉽게 Mock 오브젝트로 대체할수 있기 때문입니다.

관심사의 분리 원칙을 잘 지킬수 있게 됩니다.
더 이상 의존 관계의 객체의 초기화에 직접 관여할 필요가 없습니다.

또한 프로토콜을 사용한 의존성 주입은 결합도를 줄이고, 주입된 객체의 책임을 명확히 할 수 있습니다.

끝으로 어디서 주워들은 멋진 문장 말하고 저는 가겠습니다!🏃🏻‍♀️

Do not depend on Concretion.

Depend on Abstraction.

오늘도 나는 성장했다!!!!✊🏻

---

🤖🟢[우짱의 iOS 블로그]🔵💻

iOS를 공부하면서 배운 내용을 기록하고 있습니다.

참고 자료
https://www.youtube.com/watch?v=-n8allUvhw8
https://www.youtube.com/watch?v=sHLd1BuW0aU&t=2s
https://daniel-sumara.medium.com/removing-singletons-4340c6f6398a