[Swift] Delegate, Notification, KVO

애플리케이션 개발 시 흔히 경험하는 공통적인 문제는 과도한 커플링 없이 컨트롤러 간의 소통을 허용하는 방법이다. iOS에서 나타내는 3가지 일반적인 패턴은 다음과 같다.

 

1. Delegation
2. Notifications through Notification Center
3. Key Value Observing

 

3가지 패턴이 나오게 된 배경

💡 한 객체가 다른 객체와 묶이기 (coupled)는 싫지만, 소통은 하고 싶을 때

 

3가지 패턴은 모두 특정 이벤트가 발생하면 원하는 객체에 알려주고 처리를 한다.

어플리케이션 특성 상 객체 간 소통은 필수적이지만 한 객체는 그 자체로 존재하면서 소통할 뿐, 다른 객체에 종속되어 동작하는 것은 재사용성과 독립된 기능요소 측면에서 좋지 않다.

예를 들면 우리는 한 VC가 다른 VC와 결합하지 않고 독립적으로 존재하기를 바란다. 그렇기 때문에 Delegation, Notification, KVO를 사용한다.

 

1. Delegate

• Delegate는 Protocol을 정의하여 사용한다.
• Protocol은 Delegate로 지정된 객체가 사용할 메소드들을 구현은 하지 않고 정의만 한다.
• Delegate로 지정된 객체는 이 프로토콜을 채택하고, 프로토콜에 정의된 메소드를 구현해야 한다.
• 객체는 이벤트 발생 시 Delegate로 지정된 객체에게 알리고, Delegate로 지정된 객체가 이벤트를 대신 처리한다. 객체는 자신의 delegate가 누구인지 알지 못한다.
• 주로 1:1로 이벤트를 전달할 때 사용한다.

// #1. 프로토콜 정의
protocol SideViewDelegate {
        func sideViewButtonDidTapped(_ button: UIButton)
}

class SideView: UIView {
        // #2. 다른 객체에게 기능을 위임하기 위한 delegate 프로퍼티
        var delegate: SideViewDelegate?

        @objc func sideViewButtonTapped(_ sender: UIButton) {
                // #3. SideView의 Delegate를 가진 객체는 delegate 프로퍼티를 통해 sideViewButtonDidTapped 메소드를 실행시킨다.
                delegate?.sideViewButtonDidTapped(sender)        }
}

class ViewController: UIViewController {

        let sideView: SideView = {
                let view = SideView()
                view.translatesAutoresizingMaskIntoConstraints = false
        return view
        }()

        override func viewDidLoad() {
                super.viewDidLoad()

                // #6. sideView의 delegate 역할을 하는 VC
                sideView.delegate = self
        }
}

// #4. Delegate 채용
extension ViewController: SideViewDelegate {
        // #5. 프로토콜에 정의된 메소드 구현
    func sideViewButtonDidTapped(_ button: UIButton) {
        print("SideView의 Button이 Tapped되었어용")
    }
}

장점

• 엄격한 Syntax로 인해 프로토콜에 필요한 메소드들이 명확히 명시된다.
• 컴파일 시 경고/에러로 구현되지 않은 프로토콜의 메소드를 알려준다.
• 프로토콜이 컨트롤러 범위 내에서 정의된다.
• 로직의 흐름을 따라가기 쉽다.
• 프로토콜 메소드로 알려주는 것뿐만 아니라, 정보를 받을 수 있다.
• 커뮤니케이션 과정을 유지하고 모니터링하는 제 3의 객체 (NotificationCenter 같은 외부 객체)가 필요 없다.
• 프로토콜이 컨트롤러 범위 내에서 정의된다.

단점

• 많은 코드가 필요하다.
• 크래시가 발생할 수 있기 때문에 delegate 설정에 nil이 들어가지 않도록 주의해야한다.
• 많은 객체들에게 이벤트를 알리는 것이 어렵고 비효율적이다.
• 순환 참조를 만들어낼 수도 있기 때문에 delegate 프로퍼티를 weak로 선언하기도 한다.

 

2. Notification

• Notification Center라는 싱글톤 객체를 통해 이벤트들의 발생 여부를 옵저버를 등록한 객체들에게 Notification을 post하는 방식으로 사용한다.
• Notification은 NSNotification 클래스로 구현되어있고, Notification.Name이라는 key 값을 통해 보내고 받을 수 있다.
• UserInfo 딕셔너리를 통해 연관된 데이터를 함께 전달할 수 있다.
• 객체들이 주고 받는 메시지이므로, 사용자들에게 시각적인 알림을 전달하지 않기 때문에 별도의 허가 없이 자유롭게 사용할 수 있다. (Authorization Not Required)
• Notification이 post되면 즉시 해당 Notification을 처리하는 모든 Observer에게 전달된다. (Foreground, Background)
• 주로 1:N으로 이벤트를 전달할 때 사용한다.

폰트를 선택하고 폰트 정보를 Notification으로 전달하는 TableViewController

Notification을 통해 선택된 폰트 정보를 보낸다.

class SelectFontTableViewController: UITableViewController {

        func selectFont(theme: FontStyle) {
        if theme == .mapoFlowerIsland {
            Common.AppFontName.regular = "MapoFlowerIsland"
        } else if theme == .cafe24SurroundAir {
            Common.AppFontName.regular = "Cafe24SsurroundAir"
        } else if theme == .sdMisaeng {
            Common.AppFontName.regular = "SDMiSaeng"
        } 

                // Notification
        DispatchQueue.global().async {
            NotificationCenter.default.post(name: NSNotification.Name.FontStyleDidChange, object: nil, userInfo: ["FontStyle": Common.AppFontName.regular])
        }
    }


    override func viewDidLoad() {
        super.viewDidLoad()

        let fontStyle = Common.AppFontName.regular

        if fontStyle == "MapoFlowerIsland" {
            selectFont(theme: .mapoFlowerIsland)
        } else if fontStyle == "Cafe24SsurroundAir" {
            selectFont(theme: .cafe24SurroundAir)
        } else if fontStyle == "SDMiSaeng" {
            selectFont(theme: .sdMisaeng)
        }
    }


    override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        switch indexPath.row {
        case 0:
            selectFont(theme: .mapoFlowerIsland)
        case 1:
            selectFont(theme: .cafe24SurroundAir)
        default:
            selectFont(theme: .sdMisaeng)
        }
    }
}

 

폰트 정보 Notification을 받는 ViewController

SelectFontViewController에서 폰트가 선택되어서 보내는 Notification을 FontPreviewController에서 구독한다.

class FontPreviewViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()

        fontTextView.font = UIFont(name: Common.AppFontName.regular, size: 14)

                // 옵저버를 통해 구독한다.
        NotificationCenter.default.addObserver(self, selector: #selector(process(notification:)), name: Notification.Name.FontStyleDidChange, object: nil)
    }

        // 옵저버 해제
    deinit {
        NotificationCenter.default.removeObserver(self)
    }
}

장점

• 많은 줄의 코드가 필요 없이 쉽게 구현할 수 있다.
• 다수의 객체들에게 동시에 이벤트의 발생을 알려준다.
• Notification과 관련된 정보를 Any? 타입의 object, [AnyHashable: Any]? 타입의 userInfo로 전달할 수 있다.

단점

• key 값으로 Notification의 이름과 userInfo를 서로 맞추기 때문에 컴파일 시 구독이 잘 되고 있는지, 올바르게 userInfo의 value를 받아오는지 체크할 수 없다.
• 추적이 어려울 수 있다.
• Notification post 이후 정보를 받을 수 없다.

 

3. Key Value Observing (KVO)

• A 객체에서 B 객체의 프로퍼티가 변화됨을 감지할 수 있는 패턴
• 위의 두 패턴이 주로 Controller와 다른 객체 사이의 관계를 다룬다면 KVO 패턴은 객체와 객체 사이의 관계를 다루는데 적합하다.
• 메소드나 다른 액션에서 나타나는 것이 아닌 프로퍼티의 상태에 반응하는 형태이다

장점

• Model과 View와 같이 논리적으로 분리된 파트 간의 변경사항을 전달하는데 유용하다.
• 두 객체 사이의 정보를 맞춰주는 것이 쉽다.
• new/old value를 쉽게 얻을 수 있다.
• key path로 observing하기 때문에 nested objects 또한 observing할 수 있다.

단점

• NSObject를 상속받는 객체에서만 사용 가능하다.
• dealloc할 때 옵저버를 지워줘야한다.
• 많은 value를 감지할 때에는 많은 조건문이 필요하다.
• objc dynamic 속성을 붙여줘야한다.

 

참고 문서

Delegation, Notification, 그리고 KVO

When to use Delegation, Notification, or Observation in iOS - Shine Solutions Group