나무's 블로그

Delegate 패턴

- 위임 패턴

- iOS를 많이 겪어보지 않았다면 생소한 패턴이다.

패턴

반복해서 나타나는 형태를 의미한다. -> 유명한 싱글턴, 팩토리, 어댑터, 옵저버 등의 디자인 패턴도 이러한 '패턴' 인 것이다.

델리게이트 패턴

객체지향 프로그래밍(OOP)에서 하나의 객체가 모든 일을 처리하는 것이 아니라 일들 중 일부를 다른 객체에 넘기는 것

효율 성 관점에서 아주 중요하다 -> 기능을 위임할 수 있는 객체가 있다는 것은 그만큼 직접 구현해야 하는 부분이 적다는 것이기 때문.

GUI 프로그램에서의 예를 들어보자

1. 마우스 버튼을 클릭한다
2. 마우스는 시리얼 케이블이나 블루투스 통신을 통해 신호를 전달한다
3. 신호는 RS232 통신 프로토콜을 이용해 메인보드를 거쳐 OS의 메시지 센터로 전달된다
4. 신호를 받은 OS는 마우스 포인터의 화면상 좌표를 확인한다
5. OS는 해당 좌표에서 활성화된 App을 확인한다
6. Delegate를 이용하여 클릭 신호가 App의 이벤트 처리 함수 onClick()에 대응하였음을 App에게 알린다
7. APp이 onClick()을 실행한다.

-> 이러한 순차적인 동작을 우리는 직접 처리하지 않는다. 하지만, 클릭 이벤트에 대응되는 메소드를 작성하면 동작한다.

-> 이것은 클릭을 인식하고 App에게 전달해주는 위임(Delegate) 객체가 있기 때문

in iOS

iOS에서도 같은 개념이다. 기능을 처리할 객체를 Delegate로 설정하고, 특정 이벤트가 발생할 때 이를 Delegate에 의해 위임된 본래의 객체로 전달해주는 역할이다.

예)

메세지를 전달하기 위해 사용되는 Delegate 프로토콜

protocol MessageDelegate: class{
	func printMessage(msg: String)
}

- class를 선언한 이유 : class에서만 사용이 가능하다

대리자(프로토콜 채택)

class MainViewController: UIViewController, MessageDelegate{
	...
    //채택한 프로토콜 준수하기 위한 메소드 구현
    func printMessage(msg: String){
    	print(msg)
    }
    
}

일을 넘긴 자(위임자)의 어떠한 부분을 대신 처리해주는 객체인 대리자이다

선언했던 Delegate 프로토콜을 채택하였으며, 채택한 프로토콜을 준수하기 위해 메소드를 구현했다

위임자의 어떠한 이벤트 발생 시, 해당 메소드가 호출된다고 생각하면 된다.

만약 SecondViewController가 있고 해당 객체에서 대리자(MainViewController)에게 일을 위임하고 싶다면, 서로의 '존재' 정도는 알아야하지 않겠는가

-> 즉, 위임자가 자신의 대리자가 누구인지는 알아야 일을 부탁하던 요청하던 짬때리던 할 것 아닌가?

-> 따라서 위임자의 대리자가 MainViewController라는 것을 설정해야 한다.

위임자의 대리자 설정

//SecondVC에 대리자를 할당하기 위한 변수 선언
//참조 사이클을 회피하기 위해 약한 참조로 선언
class SecondViewController: UIViewController{
	...
    weak var delegate: MessageDelegate?
    ...
    
    @IBAction func tappedPrintButton(_ sender: Any){
    	delegate?.printMessage("여기다 적고 싶은 말")
    }
    
}

//MainViewController에 추가

class MainViewController: ....{
	...
    
    @IBAction func tappedNextButton(_ sender: Any){
		let vc = SecondViewController()
        //SecondVC의 대리자가 self(자신)이라고 설정
        vc.delegate = self
        self.present(vc, animated: true, completion: nil)
    }
    
    ...
    
}

이렇게 작성하면 정상적으로 동작하는 것을 볼 수 있다.

정리

1. 위임자가 대리자에게 어떤 일을 맡길 지 선언한다(위의 '메세지를 전달하기 위해 사용되는 Delegate 프로토콜')
2. 위임자는 대리자에게 자신의 일들 중 일부를 맡긴다
   1. 따라서 위임자는 대리자가 누구인지 알아야한다 (위의 '위임자의 대리자 설정')
3. 대리자는 위임자가 나에게 일을 시켰을 때, 작업할 동작을 구현한다. (위의 '대리자(프로토콜 채택) ')

같은 동작을 하는 클로저 콜백 방식

class MainViewController: UIViewController{
	...
    let secondVC = SecondViewController()
    
	func setClosureCallback(){
        secondVC.printMessage = { str in
        	print(str)
        }
    }
    
    @IBAction func tappedNextButton(_ sender: Any){
    	present(secondVC, animated: true, completion: nil)
    }
}


class SecondViewController: UIViewController{
	var printMessage: (String) -> Void)?
    
    @IBAction func tappedPrintButton(_ sender: Any){
    	printMessage?("여기다 적고 싶은 말")
    }
    
}

Delegate 방식과 클로저 콜백 방식 두가지 예제는 모두 같은 동작을 한다.

그러면 뭘 써?

사실 델리게이트 패턴이라는 말을 많이 들어서 만능인 줄 아는 사람들이 많다. 물론 나도 그렇다

하지만 위처럼 델리게이트 패턴이 아닌 클로저를 전달하므로써 똑같은 동작을 구현할 수 있다.

물론 이전 포스팅에서 알아본 NotificationCenter를 사용해도 가능하다.

각 방법을 사용하기 좋을 때가 있다고는 하는데 너무 다양한 의견이 많아서 정리하기가 힘들다.

그래서 나도 나만의 생각을 얘기해보겠다.

Delegate

장점 : 재사용할 수 있는 코드를 작성 가능(프로토콜의 장점)

단점 : delegate 사용을 위해 구현해야 하는 코드가 많다, 다수의 객체들에게 이벤트를 호출하는 방식이 비효율적

Notification

장점 : 옵저버에 추가한 다수의 객체들에게 동시에 이벤트를 발송 가능, 코드가 짧음

단점 : 코드의 흐름을 이해하기 어려울 수 있음

클로저 콜백

장점 : 쉽게 코드의 흐름을 파악할 수 있음

단점 : 많은 클로저를 사용해야 하는 경우 코드가 방대해짐

NotificationCenter

애플 공식 문서에는 이렇게 적혀있다

A notification dispatch mechanism that enables the broadcast of information to registered observers.

등록된 Observer들에게 정보를 BroadCast할 수 있는 알림 발송 메커니즘

이전에 사용했을 때는 주로 키보드가 올라올 때, 내려갈 때 TextField가 가려지는 문제를 해결하기 위해서 사용한 경험이 있다.

오늘은 좀 더 자세히 알아보자

어떤 객체가 Post를 하면 Observe하고 있던 Observer들에게 BroadCast를 한다.

(....? Delegate랑 똑같은 거 아냐?)

맞다. 어떤 객체가 다른 객체와 소통/송수신 한다는 메커니즘은 같다

Delegate 패턴의 사용 예

protocol SomeDelegate{
	func sayName(name: String)
}

class FirstView: UIView{
	// 순환 참조 사이클을 막기 위해 강한 참조가 아닌 약한 참조로 선언한다
    // 이벤트를 발생할(책임을 전가하는) 타입에서는 Delegate를 프로퍼티로 선언한다
	weak var delegate: SomeDelegate?
    
    func tappedButton(){
    	delegate?.sayName(name: "tree")
    }
}

// 동작을 수행할 타입에는 Delegate를 채택한다
class SomeController: SomeDelegate{
	var view: SomeView = SomeView()
    
    init(){
    	view?.delegate = self
    }
    
    // SomeDelegate 채택 후, 준수
    func sayName(name: String){
    	print(name) // tree
    }
    
} 

크게 5가지만 생각하면 된다

1. Delegate 패턴을 위한 Protocol 선언
2. 책임을 전가할 타입(위임자)에서 delegate를 프로퍼티로 선언 -> 이때, 순환 참조 사이클을 막기 위해 약한 참조 사용
3. 동작을 수행할 타입(대리자)에서 delegate를 채택
4. 위임자에 있는 delegate를 대리자의 객체로 초기화
5. 대리자에서 프로토콜을 준수

장점 : 코드를 이해하며 따라가기 쉬움

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

Notification

- NotificationCenter 라는 싱글톤 객체를 통해 이벤트들의 발생 여부를 옵저버에게 알림.

- Notification.Name 이라는 Key 값을 통해 Post/Observe 가능

class PostVC: UIViewController{
	@IBOutlet var button: UIButton!
    
    @IBAction func sendNotification(_ sender: UIButton){
    	NotificationCenter.default.post(name: Notification.Name("buyEmoticon"), object: nil)
    }
}


class ViewController: UIViewController{
	override func viewDidLoad(){
    	super.viewDidLoad()
        
        NotificationCenter.default.addObserver(self, selector: #selector(sayHello(noti:)), name: Notification.Name("buyEmoticon"), object: nil)
        
    }
    
    deinit{
    	NotificationCenter.default.removeObserver(self)
    }
    
    @objc func sayHello(noti: Notification){
    	print("Hello") // Hello
    }
}

장점

• 많은 줄의 코드가 필요없이 이벤트/동작을 구현할 수 있다
• 다수의 객체들에게 동시에 이벤트의 발생을 알려줄 수 있음

단점

• 추적이 쉽지 않음
• post 이후 정보를 받을 수 없음

결론

1. 가능하다면 Delegate로 구현하되, 하나의 이벤트로 다수의 객체에서 어떠한 동작을 해야하는 경우에만 NotificationCenter를 사용
2. NotificationCenter를 사용해야 하는 이벤트들의 경우 NotificationCenter 사용