Dependency injection is a 25-dollar term for 5-cent concept
- James Shore
"의존(依存)'은 '다른 것에 의지하여 존재함."
class A {
var b = B()
}
class A {
var b
init(b: B) {
self.b = b
}
}
// 혹은
// 밖에서
var a = A()
a.b = b()
class A {
var b: B?
}
두 가지 방법이 있는 것은 알겠습니다. 이걸 하면 도대체 무엇이 장점일까요?
사실 위 예시코드로는 이점을 얻었다고 하긴 힘듭니다. 왜냐하면, protocol
이 있을 때, 저는 의존성 주입에 대해서 장점이 생긴다고 생각합니다. 아래처럼요.
protocol 노트북기능 {
func 디스플레이송출()
func 사운드출력()
func 와이파이연결()
}
class 비보북: 노트북기능 {
func 디스플레이송출() {
120Hz송출()
}
...
}
class 맥북: 노트북기능 {
func 디스플레이송출() {
레티나디스플레이()
}
...
}
class 우노 {
var 노트북: 노트북기능
...
init(노트북: 노트북기능) {
self.노트북 = 노트북
}
}
let macbook = 맥북()
let normalLaptop = 비보북()
// #1
let uno = 우노(노트북: 맥북)
// #2
let uno = 우노(노트북: 비보북)
의존성 주입이라는 말은, 원하는 객체를 언제 전달해줄지에 관한 질문이라고 정리할 수 있겠습니다. 그 과정에서 "Protocol"이 유용한 개념이 되겠구요.
장점이라고하면
유지보수에 유리해진 구조를 가진다.
-> 프로토콜만 채택하면 새로운 객체 어느것이든 구성해서 넣을 수 있으니까요.
테스트터블한 구조
-> 의존성 주입 == input 이니 그것에 대한 output을 테스트하면 되는 비교적 단순한 테스터블한 구조(물론 이것 하나로 되는 것은 아니라고 봅니다만, 시작점이라고 생각합니다.)
확장성
-> 확장성은 이미 느끼셨겠죠? 노트북에 들어갈 객체를 생성할 때, 그냥 프로토콜만 채택해서 구현하고 넣으면됩니다.
단점이라고하면
의존성 주입 시점에 대한 동료들간의 합치가 있어야함.
-> 동료들간 의존성 주입을 다르게한다면, 코드가 상당히 복잡해질 우려가 있겠죠? (저같은 경우 required init을 활용해서 강제하려고 노력합니다. 옵셔널 선언 후 서브스크립트로 전달하는 경우는 시간이 지난다음 코드를 보거나 다른 사람이 보면 빼먹고 의존성 주입을 안해줄 우려가 조금이나마 남아있으니까요.)
https://wlgusdn700.tistory.com/m/124
https://sihyungyou.github.io/iOS-dependency-injection/
https://silver-g-0114.tistory.com/143