Notifiaction Center VS Delegate Pattern

두 가지 방식의 사용법보다는 차이점에 초점을 맞춰 공부를 해보았다.

(사용법은 따로 올릴 예정)

Delegate ? Notification? 그게 뭔데?

Delegates와 Notification 방식은 독립적인 기능을 하는 객체끼리 소통을 하기 위해 사용된다.

즉 A라는 뷰컨트롤러와 B라는 뷰컨트롤러가 있을 때, A에서 B로 알림을 보내 특정 동작을 실행하고 싶을 때 사용하는 것이다.

Delegate 패턴

Delegate 패턴이란?

delegate = 위임 → 한 객체가 자신의 책임을 다른 객체에게 위임 시키는 디자인 패턴

1. 지정된 객체가 해야하는 메서드들의 원형을 프로토콜 형태로 정해놓는다.
2. 위임을 시키는 객체에서 해당 프로토콜형식의 델리게이트 프로퍼티를 가지고 있고, 프로퍼티 내부 함수를 적절한 위치에서 실행시키도록 한다.
3. 위임받는 객체에서 프로토콜을 위임받아 프로토콜 내부의 메서드들을 구현하는 것이다.

Delegate 패턴의 쓰임

델리게이트 패턴은 IOS 구현에 있어서 엄청 많이 쓰인다.

우리가 보편적으로 사용하는 테이블뷰, 컬렉션뷰, 텍스트필드 등의 델리게이트들도 이에 해당한다.

즉 테이블뷰가 할 일을 우리는 델리게이트를 이용해 구현하는 뷰컨트롤러에서 위임하여 작성할 수 있는 것이다.

 

왜 이렇게 하는 걸까?

우리는 UITableView의 내부 코드를 수정할 수 없다. 또한 테이블뷰에서는 셀을 클릭했을 때나 무언가 변화가 있을 때 대응하는 코드를 미리 작성해 놓을 수 없다. 앱마다, 테이블 뷰마다 기능이 다르기 때문이다.

따라서 테이블뷰와 뷰컨트롤러 객체를 연결시켜 주기 위해 delegate를 사용한다.

 

 

가장 처음 델리게이트 패턴을 직접 구현했던 건 테이블 뷰 셀 안의 버튼이 있을 때 버튼 액션을 구현하기 위해 사용하였다.

그냥 단순히 해당 셀에만 영향을 준다면 델리게이트 패턴을 사용하지 않았겠지만,

예를 들어 TodoList의 삭제 버튼을 구현한다고 생각하면, 삭제버튼을 눌렀을 때 셀이 아닌 호출한 뷰컨트롤러에 있는 투두 리스트 변수에 접근하여 요소를 삭제하고 테이블뷰를 리로드 해야 한다.

이러한 작업은 해당 뷰 컨트롤러에서 작성해야 하기 때문에 셀과 뷰컨트롤러를 delegate로 연결해 셀의 버튼 액션을 뷰컨트롤러로 위임하여 작성하였다.

Notification Center

NotificationCenter에 등록된 event 가 발생하면 옵저버를 등록한 객체들에게 Notification을 보내 해당 event에 대한 행동을 실행한다.

1. 한 객체에서 이벤트가 발생했다는 것을 Notification Center로 송신
2. Notification Center에서 발생된 이벤트를 등록된 모든 옵저버에 보냄
3. 해당 이벤트를 구독하는 Observer는 해당 화면에서 이벤트를 처리

즉 누군가 일감을 노티피케이션 센터에 넘기면

노티피케이션 센터는 전국의 옵저버들에게 name씨 일 들어왔어요~라고 방송을 한다.

그럼 name에 해당하는 옵저버는 일이 들어왔으니 해당 일에 대한 동작을 실행한다.

차이점

Delegate Notification

	Delegate	Notification
장점	프로토콜로 필요한 메서드들이 명확하게 명시 필요한 기능을 모두 구현하지 않을 경우 컴파일 시 경고나 에러로 알 수 있음 로직의 흐름을 따라가기 쉬움 제 3의 객체 없음	적은줄의 코드로 쉽게 구현할 수 있음 다수의 객체들에게 동시에 이벤트 발생 가능 관련 정보를 [AnyHashable: Any]? 타입의 객체 userInfo로 전달 가능함
단점	많은 줄의 코드 필요 다수의 객체에게 이벤트를 알려주는 것이 어렵고 비효율적임	key값 불일치 시 제대로 구독이 안될 수 있음 (확인이 어려움) → Key 값을 namespace로 선언해두기 로직 흐름을 따라가기 어려움 Post 이후의 정보를 받을 수 없음

 

• 다수의 객체들에게 정보를 전달하는 경우 → Notification 사용
• 그 외 경우 Delegate 사용 ⇒ 로직 흐름을 이해하기 쉽고 유지보수 쉬움