Key-Value Observing(KVO) in Swift

 

안녕하세요 :) Zedd입니다.

오늘은 KVO에 대해서 공부!

 

# KVO

- Key-Value Observing의 약자

- 객체의 프로퍼티의 변경사항을 다른 객체에 알리기 위해 사용하는 코코아 프로그래밍 패턴

- Model과 View와 같이 논리적으로 분리된 파트간의 변경사항을 전달하는데 유용함

- NSObjec를 상속한 클래스에서만 KVO를 사용할 수 있음.

 

그럼 예제를 통해 보겠습니다.

Key-Value Coding(KVC) / KeyPath in Swift에서 사용한 예제를 가져와볼게요.

 

# Observing을 위한 Setup

class Address {
    var town: String
    
    init(town: String) {
        self.town = town
    }
}

Zedd : 나는 town이 변경하는 걸 다른 객체에게 알리고싶어! 

라고 했을 때 해야하는 작업이 2가지 있습니다. 

1. NSObjec 상속 ➞ NSObjec를 상속한 클래스에서만 KVO를 사용할 수 있기 때문 ➞ 상속을 해야하므로 class에서만 사용 가능

2. observe하려는 프로퍼티에 @objc attribute와 dynamic modifier를 추가해야합니다. 

class Address: NSObject {
    @objc dynamic var town: String
    
    init(town: String) {
        self.town = town
    }
}

자 이렇게 해줬습니다.

 

# Observer 정의 

내가 observe하려는 프로퍼티가 변경되는지 봐야할거아니에요?

그래서 observer가 필요합니다.

var address = Address(town: "어쩌구")

address.observe(\.town, options: [.old, .new]) { (object, change) in
    print(change.oldValue, change.newValue)
}

저번시간에 배운 KeyPath를 사용하여 프로퍼티 KeyPath에 observer를 추가할 수 있습니다. (\.town)

그럼 address의 town값을 변경해보겠습니다.

var address = Address(town: "어쩌구")
address.observe(\.town, options: [.old, .new]) { (object, change) in
    print(change.oldValue, change.newValue) // Optional("어쩌구") Optional("바보")
}
address.town = "바보"

1. town을 바보로 바꿈

2. 프로퍼티에 변경사항이 생김

3. observer의 change handler가 호출됨

4. handler내에서 oldValue와 newValue를 가져올 수 있음

그래서 

Optional("어쩌구") Optional("바보") 

가 출력되는 것을 볼 수 있어요.

 

address.observe(\.town, options: [.old, .new]) { (object, change) in
    print(change.oldValue, change.newValue) // ✔️ Optional("어쩌구") Optional("바보")
}

지금 options에 이렇게 [.old, .new]가 추가되어있는 것을 볼 수 있는데요.

만약 변경사항이 필요하지 않으면 options를 안주면 됩니다.

var address = Address(town: "어쩌구")
address.observe(\.town) { (object, change) in
    print(change.oldValue, change.newValue) // ✔️ nil nil
}
address.town = "바보"

그럼 이렇게 nil이 출력되게 됩니다.

 

options에는

- old

- new

- initial

- prior

이렇게 4가지의 값이 들어갈 수 있습니다.

old와 new는 봤으니 넘어가고

 

[initial]

initial은 초기화시에도 이 observer handler를 호출할거냐...라고 보면 될 것 같습니다.

var address = Address(town: "어쩌구")
address.observe(\.town, options: [.old, .new]) { (object, change) in
    print(change.oldValue, change.newValue) // Optional("어쩌구") Optional("바보")
}
address.town = "바보"

 우리가 초기값을 어쩌구로 줬는데, 이제 town을 바보로 변경했을 때 handler가 불리는데요,

나는 초기값에 대해서도 handler가 불리게 하고싶다!고 하면 initial을 추가해주면 됩니다.

var address = Address(town: "어쩌구")
address.observe(\.town, options: [.old, .new, .initial]) { (object, change) in
    print(change.oldValue, change.newValue)
    // nil Optional("어쩌구")
    // Optional("어쩌구") Optional("바보")
}
address.town = "바보"

이렇게요! 어쩌구는 newValue로 들어갔네요. 

 

[prior]

이전의 상태와 지금의 상태를 다 주는(?) 옵션이라고 볼 수 있습니다.

var address = Address(town: "어쩌구")
address.observe(\.town, options: [.old, .new, .prior]) { (object, change) in
    print(change.oldValue, change.newValue)
    // Optional("어쩌구") nil
    // Optional("어쩌구") Optional("바보")

}
address.town = "바보"

 

자..initial이 없으니 따로 초기화할 때 handler가 불리지 않습니다.

바보로 바꿔준 순간 handler가 호출이 되는데요 위에서 봤을 때처럼 

Optional("어쩌구") Optional("바보")

이렇게만 나오는게 아니라

 // Optional("어쩌구") nil

// Optional("어쩌구") Optional("바보")

이렇게 2개가 호출되네요.

prior. 즉 "이전"이라는 말답게..이전의 상태도 같이 준다는 것을 알 수 있습니다.

initial이 된 순간 어쩌구는 oldValue로 취급되고 newValue는 없는 상태였죠.

프로터티가 변경된 순간 newValue는 바보가 됩니다.

이해하셨나요!? 

 

 

handler의 파라미터로 change말고 제가 object라고 해준것도 있었는데요.

object에는 현재 address의 town값이 들어가게 됩니다.

그래서 현재 바보로 바뀌었으니 && prioir 옵션이 함께 있으니

이전값인 어쩌구와

현재값인 바보가 함께 출력되는 것을 볼 수 있습니다.

 

만약 이게 이전값인지..현재값인지 알고싶다면

change의 isPrior 프로퍼티를 통해 확인하면 됩니다.

true면 이전값, false면 현재값입니다.

 

KVO에 대한 설명은 끝났습니다.

KVO를 보시고 다음과 같은 궁금증이 생길 수 있습니다. 

Q : oldValue, newValue..? 프로퍼티 옵저버(willSet, didSet)랑 비슷하군..

class Address: NSObject {
    var town: String {
        willSet { print(newValue) }
        didSet { print(oldValue) }
    }
    
    init(town: String) {
        self.town = town
    }
}

A : 네 KVO와 비슷한건 맞는데, 위 코드 처럼 프로퍼티 옵저버는 타입 정의 내부에 위치해야 하는 반면,
KVO는 타입 정의 외부에서 obsever를 추가할 때 사용하는 거라고 보면 됩니다!

 

# KVO의 장점과 단점

[장점]

1. 두 객체간의 동기화를 달성가능. 위에서 언급했듯이 Model과 View와 같이 논리적으로 분리된 파트간의 변경사항을 전달 ➞ 동기화 가능

2. 객체의 구현을 변경하지 않고 내부 객체의 상태 변화에 대응할 수 있음. (SDK객체의 경우)

장점을 여기를 참고하는 중인데..꽤나 많은 곳에서 이 KVO의 장점에 대해 2번을 꼽더라구요.

예를 들어 라이브러리에 들어있는 프로퍼티의 변경사항을 알고싶다!
➞ 내가 내부 구현을 못바꾸니(프로퍼티 옵저버 이런걸 추가 못하니) KVO가 이럴때 좋음..이라고 하는데..

만약 해당 클래스가 NSObject를 상속받고 있지 않고 @objc dynamic도 붙어있지 않다면 못하는거 아닌가요..?
이게 장점이라고 말하긴 좀 그럴 것 같은데...암튼 제 생각입니당..ㅎㅎ

3. 관찰된 프로퍼티의 이전값(oldValue)와 최신값(newValue)를 제공

4. KeyPath를 사용하여 프로퍼티를 관찰하므로 nested 프로퍼티도 관찰 가능 

class Address: NSObject {
    @objc dynamic var town: String
    
    init(town: String) {
        self.town = town
    }
}

class Person: NSObject {
    @objc dynamic var address: Address
    
    init(address: Address) {
        self.address = address
    }
}

이런식으로 해서 person인스턴스에서 \.address.town 이렇게 관찰도 가능하다는 뜻

5. 따로 옵저버를 해제해주지 않아도 됨. 시스템이 알아서 removeObserver해줌 

 

[단점]

1. NSOject 상속해야됨 == Objective-C 런타임에 의존하게 됨. 

2. 이건 제가 생각한 단점인데...

예를 들어

 1. 내가 구현함 && struct임

이럴 때 프로퍼티 옵저버를 사용하면 Static dispatch를 사용하게 되어서 성능상의 이점을 가져갈 수 있는데, 

2. 내가 구현함 && class임

클래스는 기본적으로 dynamic dispatch를 사용하잖아요?

근데 static dispatch를 사용할 수 있을때는 static dispatch를 사용하는데..

dynamic을 붙힘으로서 무조건 dynamic dispatch를 사용하게 되는거 아닐까요?!...

예를 들어 town이 final이라고 했을 때 (또는 컴파일러가 final로 유추할 수 있을때) 

이때는 static dispatch를 할 수 있지만

dynamic때문에 dynamic dispatch를 하게 되는...

그래서 굳이 따지자면 성능측면에서 안좋다..??

 

이거 같은 경우에는 Swift) dynamic이란? / Realm의 dynamic var는? 글을 보고 추측해보았읍니다..

틀린점이 있다면 말씀해주세요~🇰🇷🇰🇷

 

 

참고 

www.hackingwithswift.com/example-code/language/what-is-key-value-observing

developer.apple.com/documentation/swift/cocoa_design_patterns/using_key-value_observing_in_swift