Delegate vs Block vs Notification vs KVO
하나의 객체가 다른 객체와 소통은 하지만 묶이기(coupled)는 싫을 때
Delegate
Delegate는 보통 Protocol을 정의하여 사용한다.
Protocol이란 일종의 기능 명세서 같은 것으로 Delegate로 지정된 객체가 해야 하는 메소드들의 원형을 적어 놓는다.
Delegate 역할을 하려는 객체는 이 Protocol을 따르며 원형만 있던 메소드들의 구현을 한다.
이렇게 세팅 후 이전 객체는 어떤 이벤트가 일어났을 시 delegate로 지정한 객체에 알려줄 수 있다.
장점
매우 엄격한 Syntax로 인해 프로토콜에 필요한 메소드들이 명확하게 명시됨.
컴파일 시 경고나 에러가 떠서 프로토콜의 구현되지 않은 메소드를 알려줌.
로직의 흐름을 따라가기 쉬움.
프로토콜 메소드로 알려주는 것뿐만이 아니라 정보를 받을 수 있음.
커뮤니케이션 과정을 유지하고 모니터링하는 제 3의 객체(ex: NotificationCenter 같은 외부 객체)가 필요없음.
프로토콜이 컨트롤러의 범위 안에서 정의됨.
단점
많은 줄의 코드가 필요.
delegate 설정에 nil이 들어가지 않게 주의해야함. 크래시를 일으킬 수 있음.
많은 객체들에게 이벤트를 알려주는 것이 어렵고 비효율적임.(가능은 하지만)
Block
이벤트가 딱 하나일 때 사용하기 좋습니다.
Completion block 을 사용하는 것이 좋은 예로 NSURLConnection sendAsynchronousRequest:queue:completionHandler:가 있습니다.
Notification
Notification Center라는 싱글턴 객체를 통해서 이벤트들의 발생 여부를 옵저버를 등록한 객체들에게 Notification을 post하는 방식으로 사용한다.
Notification name이라는 key 값을 통해 보내고 받을 수 있다.
장점
많은 줄의 코드가 필요없이 쉽게 구현이 가능.
다수의 객체들에게 동시에 이벤트의 발생을 알려줄 수 있음.
과 관련된 정보를 Any? 타입의 object, [AnyHashable: Any]? 타입의 userInfo로 전달할 수 있음.
단점
key 값으로 Notification의 이름과 userInfo를 서로 맞추기 때문에 컴파일 시 구독이 잘 되고 있는지, 올바르게 userInfo의 value를 받아오는지 체크가 불가능함.
추적이 쉽지 않을 수 있음.
Notificaiton post 이후 정보를 받을 수 없음.
Key Value Observing(KVO)
KVO는 A 객체에서 B 객체의 프로퍼티가 변화됨을 감지할 수 있는 패턴이다.
위의 두 패턴이 주로 Controller와 다른 객체 사이의 관계를 다룬다면 KVO 패턴은 객체와 객체 사이의 관계를 다루는데 적합하다. (물론 다룰수야 있다.)
메소드나 다른 액션에서 나타나는 것이 아니라 프로퍼티의 상태에 반응하는 형태이다.
장점
두 객체 사이의 정보를 맞춰주는 것이 쉬움.
new/old value를 쉽게 얻을 수 있음.
key path로 옵저빙하기 때문에 nested objects도 옵저빙이 가능함.
단점
NSObject를 상속받는 객체에서만 사용이 가능함.
dealloc될 때 옵저버를 지워줘야 함.
많은 value를 감지할 때는 많은 조건문이 필요.
댓글