[Swift] Delegation, Notification, KVO

Uno·2021년 5월 7일
0

Tip-Swift

목록 보기
6/26

3 가지 모두 비슷해보이는데 차이는 무엇이고 각각 사용처가 어떻게 다를까?
위 질문때문에 이 글을 작성하게 되었습니다.

3 가지 방법이 있으면, 3 가지의 사용 이유가 있지 않을까요?

Delegation, Notification, KVO 가 생긴 이유

각각의 객체가 각각 존재 + 소통

위 두 조건을 만족시키고자 3 가지 패턴이 발생하게 되었습니다.
Controller는 하나의 View와 종속되어있습니다. 그렇다면 다른 Controller의 View는 조작(혹은 소통) 할 수 없겠죠?
그렇지만 하고 싶습니다. 하고 싶기 때문에 위 패턴들이 등장하게 된 것이죠.

각각 존재하면서 필요할 때만 이야기하고 싶다.
꼭 2021 20~30대가 원하는 삶같아요. 각자 살지만 원할때는 이야기하고 싶은..?

Delegation

로그인했는데 UI를 모두 변경하고 싶네. 내가 너 View를 조작할 수는 없으니까 너가 대신해줘!

위와 같은 상황에서 Delegation을 사용하기도 합니다.
(물론 로그인 시, 많은 View가 변경되어야 한다면 말이 달라지겠지만요.)

Swift 공식 문서의 정의를 다음과 같이 해석했습니다.

위임은 클래스 또는 구조가 ::책임의 일부::를 다른 유형의 인스턴스에 넘겨 주거나 ::위임:: 할 수 있도록하는 디자인 패턴입니다. 이 디자인 패턴은 위임 된 책임을 캡슐화하는 ::프로토콜::을 정의하여 ::구현::됩니다. 따라서 준수 형식 (대리자라고 함)이 위임 된 기능을 제공하도록 보장됩니다. 위임은 특정 작업에 응답하거나 해당 소스의 기본 유형을 알 필요없이 외부 소스에서 데이터를 검색하는 데 사용할 수 있습니다.
(출처 : https://docs.swift.org/swift-book/LanguageGuide/Protocols.html)

요약하자면,
::델리게이션::을 구현하는 것이 ::목적::인 것이고 그것을 행하도록 도와주는 것이 ::프로토콜::이라는 ::수단::입니다.

구현 방법이나 구체적인 정보는 다시 다루겠습니다. 오늘은 사용처와 목적에 대해서만 작성하겠습니다.

왜 Delegation을 써야하지그러면??
바로 다음과 같은 장단점이 있기 때문입니다.

  • 장점
- Protocol을 작성할 때, 메소드를 생성한다. 그로인해 메소드를 생성하는 것을 깜빡하는 것을 미연에 방지할 수 있다. (메소드의 동작을 작성하지 않으면 Error로 알려줌)

- "Protocol 생성->delegate메소드 사용 -> delegate 메소드 정의" 과정에서 이를 관장할 제 3의 객체가 필요없다.
  • 단점
- 코드량이 많아진다.

- 많은 객체를 호출하기 어렵다. (상대적으로 비효율적)

음.. 여기까지 설명을 보니 1:1로 커뮤니케이션할 때, 사용하면 용이할 것 같다는 생각이 듭니다.
설마나만..?

Notification

앱에 Notification Center 라는 싱글톤 객체가 있습니다. (앱 생성 시, 자동으로 생성됩니다.)
이 객체를 통해서 이벤트가 발생했는지 확인합니다. 그리고 이벤트가 발생했다면(post했다면) 이를 관찰하고 있던 관찰자에서 Action 메소드를 호출합니다.

그래서 커뮤니케이션을 어떻게하는데??
Notification Center에 노티피케이션을 등록합니다. (ex. A 노티)
A노티를 관찰하는 관찰자를 등록합니다. (첫 번째 컨트롤러에서 A노티를 관찰했습니다.)
A노티를 실행시킵니다.(post) (다른 컨트롤러에서 A노티를 부릅니다.)

그러면 첫 번째 컨트롤러와 다른 컨트롤러 사이에 커뮤니케이션이 진행되었죠.

예시를 들자면, 로그인을 성공했다고 가정합시다.

로그인을 담당하는 컨트롤러에서 로그인을 성공했으니, 로그인 성공 노티를 호출합니다.
이를 관찰하고 있던 "내정보" 컨트롤러에서 노티를 받습니다.
그리고 그 노티에 따라 이미지를 변경합니다.

그럼 이걸 왜써야하는거지?
바로 아래 장단때문이죠.

  • 장점
- 코드가 간결하다.

- 다수의 객체에 알려줄 수 있다.

- 정보를 전달할 수 있다. (키워드: userInfo)
  • 단점
- 관찰이 잘 되고 있는지 체크하는 것이 불가능하다. (직접 경험한 사실은 아니라 설명이 부족하네요 ㅠㅠ)

- 추적이 쉽지 않다.

- post 이후 정보를 받을 수 없다.

느낌상, 1:N 커뮤니케이션에 사용하면 좋을 것 같습니다.

Key Value Observing

이에 대해서는 다로 게시물을 올리겠습니다.
올리면 이곳에 링크를 걸어두겠습니다.

결론

이 글의 원본인 글쓴이는
KVO는 프로퍼티 단위의 변화 감지에 사용한다고합니다.
Delegation과 Notification이 사용처가 애매한 면이 있이므로 이 둘에 대해서 구분합니다.

Delegation을 추천합니다. 이유는 코드가 읽기 쉽다는 이유입니다. (추척이 쉽기도하고요)
음… 물론 Delegation의 이름을 보통 class명 + delegate 라고 정하기때문에, 확실히 코드가 읽기편하고 어디에 사용했는지 알기도 쉽긴 합니다.

이유가 조금 명쾌하지 않은 것은 사실입니다. Notification의 이름을 잘 작성하는 방법이 있기도 하니까요.

개인적으로 내린 결론으로

1 : 1 커뮤니케이션 => Delegation
1 : N 커뮤니케이션 => Notification
으로 잠정결론을 냈습니다.

다만, 개발경험과 다른 코드들에 대해서 배우고 나면 좀더 기준에 명확해질 것 같습니다.
기준이 명확해지면 글에 보충하겠습니다!

참고자료


profile
iOS & Flutter

0개의 댓글