iOS - 델리게이션 패턴(Delegation Pattern)

한번 정리할 때가 되었다.

그것의 이름은 델리게이션 패턴(Delegation Pattern) 이다.

iOS 개발을 하면서 흔히 보게되는 용어가 있다. 그것의 이름은 'Delegate' 

처음 이 것을 보았을 때는 그냥 이러이러 하게 쓰면 되는거구나 싶었는데, "이것은 근데 무엇일까?" 하는 의문을 갖게 되었다.

바로 해결해보자.

 

델리게이션 패턴(Delegation Pattern) 이란?

 

-  하나의 객체가 다른 '도우미' 역할의 객체를 사용하는 것이다. 왜? 어떠한 일을 수행하거나 혹은 데이터를 제공하는데 있어 객체 자신이 수행하는 것보다 오히려 다른 객체를 사용하는 것이 효율적이기 때문이다. 왜 효율적인가? 아래를 읽어내려가 보자.

 

델리게이션 패턴(Delegation Pattern) 은 크게 3 부분으로 나눌 수 있다.

 

1. 델리게이트(Delegate) 를 필요로 하는 객체

2. 델리게이트(Delegate) 를 구현한 프로토콜(Protocol)

3. 델리게이트(Delegate) 로서 행동하는 객체

 

1번) 얘는 델리게이트(Delegate) 를 가지는 객체다. 그리고 이 델리게이트(Delegate) 는 기본적으로 얘가 델리게이트를 보유하고 있게 되고 델리게이트가 얘를 보유하게 되는 retain cycle 을 피하기 위해 약한 참조(weak reference) 로 선언된다. 

 

Q. retain cycle 이요?

 ARC와 관련되어 있으니 다음의 글 https://atelier-chez-moi.tistory.com/37 을 쭉 읽어보길 바란다.

 

2번) 델리게이트(Delegate) 가 구현해야 하는 메서드들을 정의하고 있는 애가 얘다.

3번) 델리게이트 프로토콜을 구현하고 있는 도우미 객체가 얘다.

 

   왜 실제적 객체가 아닌 델리게이트 프로토콜에 의존할까? 바로 구체적으로 객체를 구현하는 것보다 훨 씬 더 유연하기 때문이다. 즉, 프로토콜을 구현하는 모든 객체가 곧 델리게이트가 될 수 있다는 것이죠. 이제 유연한 이유에 대해 좀 다가오는 것 같다.

 

  좋다. 이제 좀 델리게이션 패턴이 눈에 들어오는 것 같다. 자, 그럼 가장 중요한 것. 이거 도대체 언제 쓰는걸까? 거대해진 클래스를 분리하거나 제네릭이면서 재사용가능한 컴포넌트를 생성할 때 사용하면 된다. 아.. 이거 잘 안 다가오는데?

 

  가장 가벼운 예시는 생각보다 가까이에 있다. 애플의 프레임워크 곳곳에 델리게이트가 숨어있다. 우리가 흔히 쓰는 DataSource- / Delegate- 라는 이름의 객체들이 실제로 델리게이트 패턴을 따른다. 예를 들어 아까 하나의 객체가 다른 객체에게 데이터를 제공하도록 요청한다고 했는데, 아래의 UICollectionViewDataSource 의 경우 UICollectionViewCell 를 표시하기 위해 데이터를 제공하도록 요청하는 메서드 들을 가지고 있다. 

예시 사진

UICollectionViewDataSource 의 대표적인 Required Methods

 

  이외에도 델리게이트를 스스로 만들어내서 쓸 수 있다. 이에 대해서는 수 많은 자료들이 이를 다루고 있기 때문에 여기서는 다루지 않도록 한다.

 

  델리게이트 패턴은 매우 유용하지만, 우리가 염두해 두어야 할 것이 있다. 바로 과다한 사용을 지양하는 것이다. 즉, 하나의 객체에 대해 너무 많은 델리게이트를 생성하지 않도록 해야 한다. 

 

  그렇다면 어느 정도가 과다한가? 이에 대해서는 객관적 접근이 필요한데, 누구나 코드를 보았을 때, 너무 많은 델리게이트로 인한 혼란이 발생한다면 그것은 과다하다고 볼 수 있다. 자기 스스로 너무나 과하다 생각이 들면 주변 사람들에게 코드 리뷰를 부탁해보자 :)

 

 

지금까지 짧게 델리게이트 패턴에 대해 알아보았습니다.

부족한 글을 읽어주셔서 감사합니다.