[Swift] 객체 간 소통 및 이벤트 전달 Delegate / NotificationCenter / KVO

객체 간의 소통할 때, 결합도를 낮추고 독립적으로 작동할 수 있도록 이벤트 전달을 도와주는 방법들.
delegate가 명시적으로 쓸 수 있어 좋음. 작성할 코드가 많아서 구현이 상대적으로 어렵다. 
NotificationCenter는 사용이 간편하고, 다수의 객체들에게 동시에 이벤트 발생을 알려주기에 편리하지만 

 

Callback techniques in Cocoa

- delegation

- NotificationCenter

- Key-Value Observing

 

세 가지 패턴의 등장 배경

to allow communication between our controllers, without the need to have excessive coupling.
하나의 객체가 다른 객체와 소통은 하지만 묶이기(coupled)는 싫을 때

ways for one object to communicate events to other objects without requiring them to be coupled. ways to allow certain events to be heard by others.

세 패턴 모두 특정 이벤트가 일어나면 원하는 객체에 알려주어 해당되는 처리를 하는 방법.

객체 간 소통은 필수적이지만, 다른 객체와 종속되어 동작하는 것은 '재사용성'과 '독립된 기능 요소' 측면에서 바람직하지 않다.

따라서 Delegateion, Notification, KVO를 사용한다.

 

delegation

• Protocol (a set of method definitions) 을 정의하여 사용
• Delegate 역할을 하려는 객체는 이 Protocol을 따르며 원형만 있던 메소드들의 구현을 함
• 이렇게 세팅 후 이전 객체(SomeView)는 어떤 이벤트가 일어났을 시 delegate로 지정한 객체(SomeController)에 알려줄 수 있다.
  => 종속되어 동작하는 것이 아님. 독립적으로 떨어져 있음.

장점

(- loose coupling. 낮은 결합도 )

- Very strict syntax. 전달하고자 하는 이벤트가 delegate protocol 내에 명확하게 정의되어 있다. 

- 추적이 가능하고, 제어 흐름을 쉽게 파악할 수 있다.

- Ability to receive a returned value from a called protocol method. This means that a delegate can help provide information back to a controller.

단점

• Many lines of code required to define: 1. the protocol definition, 2. the delegate property in the controller, and 3. the implementation of the delegate method definitions within the delegate itself.
• Need to be careful to correctly set delegates to nil on object deallocation, failure to do so can cause memory crashes by calling methods on deallocated objects.
• Although possible, it can be difficult and the pattern does not really lend itself to have multiple delegates of the same protocol in a controller (telling multiple objects about the same event)

• 많은 객체들에게 이벤트를 알려주는 것이 어렵고 비효율적임

Notification

Notification Center is a singleton object that allows for objects to be notified of events occurring.

uses a key (notification name) in order to allow other objects to hear about special events occurring

other objects (observers) can react to the notification events by registering for notifications with the same key.

Notification Center라는 싱글턴 객체를 통해서 이벤트들의 발생 여부를 옵저버를 등록한 객체들에게 Notification을 post하는 방식으로 사용

• Notification Center라는 싱글턴 객체를 사용
• 다수의 객체들에게 동시에 이벤트 발생을 알려줄 수 있음
• 발행 이후 정보를 받을 수 없음
• 추적이 쉽지 않음 (변화가 언제 일어나는지 캐치를 못함?) → Center에서 관리하기 때문에?

장점

• Easy to implement, with not many lines of code.
• Can easily have multiple objects reacting to the same notification being posted.
• Controller can pass in a context (dictionary) object with custom information (userInfo) related to the notification being posted.

단점

• No compile time to checks to ensure that notifications are correctly handled by observers.
• Required to un-register with the notification center if your previously registered object is deallocated.
• Not very traceable. Attempting to debug issues related to application flow and control can be very difficult.
• Third party object required to manage the link between controllers and observer objects.
• Notification Names, and UserInfo dictionary keys need to be known by both the observers and the controllers. If these are not defined in a common place, they can very easily become out of sync.
• No ability for the controller to get any information back from an observer after a notification is posted.

 

delegation / NotificationCenter 비교

Delegate의 경우 이벤트를 받는 대상이 하나지만, Notification은 다수가 될 수 있다.

Notification의 경우 디버깅이 힘들 수 있다.

Delegate를 사용하기 위한 설계가 비교적 복잡하다.

 

kvo는 Swift 상에서는 didSet이나 willSet 같은 것으로 충분히 대체가 가능할 것 같아 굳이 써야하나 싶은 패턴인 듯

 

 

 

 

---

참고 :

https://nalexn.github.io/callbacks-part-1-delegation-notificationcenter-kvo/

Callbacks, Part 1: Delegate, NotificationCenter, and KVO

https://medium.com/@Alpaca_iOSStudy/delegation-notification-%EA%B7%B8%EB%A6%AC%EA%B3%A0-kvo-82de909bd29

https://shinesolutions.com/2011/06/14/delegation-notification-and-observation/