Delegate 패턴
- 위임 패턴
- iOS를 많이 겪어보지 않았다면 생소한 패턴이다.
패턴
반복해서 나타나는 형태를 의미한다. -> 유명한 싱글턴, 팩토리, 어댑터, 옵저버 등의 디자인 패턴도 이러한 '패턴' 인 것이다.
델리게이트 패턴
객체지향 프로그래밍(OOP)에서 하나의 객체가 모든 일을 처리하는 것이 아니라 일들 중 일부를 다른 객체에 넘기는 것
효율 성 관점에서 아주 중요하다 -> 기능을 위임할 수 있는 객체가 있다는 것은 그만큼 직접 구현해야 하는 부분이 적다는 것이기 때문.
GUI 프로그램에서의 예를 들어보자
- 마우스 버튼을 클릭한다
- 마우스는 시리얼 케이블이나 블루투스 통신을 통해 신호를 전달한다
- 신호는 RS232 통신 프로토콜을 이용해 메인보드를 거쳐 OS의 메시지 센터로 전달된다
- 신호를 받은 OS는 마우스 포인터의 화면상 좌표를 확인한다
- OS는 해당 좌표에서 활성화된 App을 확인한다
- Delegate를 이용하여 클릭 신호가 App의 이벤트 처리 함수 onClick()에 대응하였음을 App에게 알린다
- 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)
}
...
}
이렇게 작성하면 정상적으로 동작하는 것을 볼 수 있다.
정리
- 위임자가 대리자에게 어떤 일을 맡길 지 선언한다(위의 '메세지를 전달하기 위해 사용되는 Delegate 프로토콜')
- 위임자는 대리자에게 자신의 일들 중 일부를 맡긴다
- 따라서 위임자는 대리자가 누구인지 알아야한다 (위의 '위임자의 대리자 설정')
- 대리자는 위임자가 나에게 일을 시켰을 때, 작업할 동작을 구현한다. (위의 '대리자(프로토콜 채택) ')
같은 동작을 하는 클로저 콜백 방식
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
장점 : 옵저버에 추가한 다수의 객체들에게 동시에 이벤트를 발송 가능, 코드가 짧음
단점 : 코드의 흐름을 이해하기 어려울 수 있음
클로저 콜백
장점 : 쉽게 코드의 흐름을 파악할 수 있음
단점 : 많은 클로저를 사용해야 하는 경우 코드가 방대해짐
'iOS' 카테고리의 다른 글
| [iOS] 프레임워크 끄적 (0) | 2021.03.01 |
|---|---|
| [iOS] init(frame:) 과 required init?(coder:) (0) | 2021.01.27 |
| [iOS] Local Push Notification 로컬 알림 처리하기 (0) | 2021.01.21 |
| [iOS] Local Push Notification 로컬 알림 (0) | 2021.01.21 |
| [iOS] NotificationCenter vs Delegate (0) | 2021.01.19 |
