Coordinator 패턴이란

이번 글에서는 Coordinator 패턴이란 무엇인지에 대해 공부한다.

Coordinator 패턴이란

Coordinator 패턴이란 iOS 앱에서 Coordinator 객체를 만들어 화면간 전환 로직을 담당하게 만드는 패턴을 말한다.

Coordinator 패턴은 왜 필요한가

화면 전환 로직은 보통 VC(ViewController)에 두게 된다.

A VC에서 B VC로 present나 push를 통해 전환한다면, 스토리보드를 사용하는 경우 segue를 사용할테고,

코드로 구현하는 경우 B VC를 인스턴스화해서 직접 present하거나 네비게이션 컨트롤러에 push 해줄 것이다.

흔한 방식이다. 이게 왜 문제가 되는걸까?

 

가장 단순한 이유는 VC가 안그래도 비대한데 화면 전환 로직때문에 더더욱 거대해지기 때문이다.

MVC로 개발하는 경우, 기능이 조금만 많아져도 VC가 200줄은 물론 400줄 이상으로도 길어지는 경우가 많다.

여기에 화면 로직까지 더해진다면, 더더욱 길어질 것이고 화면 로직의 복잡도에 따라 결국 1000줄 이상으로 길어질 수도 있다.

 

객체는 거대할수록 가독성이 떨어진다.

명확한 하나의 책임만을 가지도록 분리해서 작게 유지하는게 가독성 측면에서 좋고 그래야 유지보수하기도 좋다.

 

다음으로 두 VC가 강하게 결합(커플링)된다는 것이 문제이다.

두 객체의 결합도가 높을때 어떤 문제가 있을까?

 

예를 들어, A VC와 B VC, C VC가 있다고 하자.

A VC에서는 C VC로 이동할 수 있고, B VC에서도 C VC로 이동할 수 있다.

그럼 우리는 A VC에 C VC를 인스턴스화하고 present 혹은 네비게이션 컨트롤러에 push하는 코드를 작성하고,

똑같은 코드를 복붙해서 B VC에도 작성해야 한다.

여기까진 뭐 문제가 없다. 문제는 C VC를 인스턴스화하는 방식이 변경될때이다.

 

우리는 A VC와 B VC에 직접 찾아가서 (아마 컴파일 에러가 나는 곳을 찾아갈 확률이 높다)

C VC를 인스턴스화하는 코드를 하나하나 고쳐야 한다.

C VC로 전환하는 경우의 수가 2개인 상황엔 큰 문제가 아니지만, C VC로 전환하는 경우의 수가 10개라면 생각이 조금 달라질 것이다.

C VC가 앱 내부에서 아주 많이 재사용된다면, 그 이상으로 코드를 수정해줘야 할 수도 있다.

 

그래서 각 VC들은 어떤 액션의 결과로 어느 VC로 이동하게될지 최대한 모르게 만들고,

실제 이동하는 VC는 상위 객체에서 관리하도록 만들어주는 것이 필요하다. (로직을 분리)

 

이외에도 다양한 이유가 더 있을 수 있으나 핵심은 재사용과 역할 분리라고 생각한다.

 

따라서 화면(VC)간의 결합도를 낮추기 위해 화면간의 전환은 상위 객체에서 관리하게 만드는데 그것이 바로 Coordinator이다.

Coordinator 패턴 적용 방법

굳이 적용 방법을 코드로 적으려고 하진 않겠다.

더 좋은 자료가 많아서이다.

 

간단한 예제로 살펴보는 iOS Design/Architecture Pattern: Coordinator - Basic

간단한 예제로 살펴보는 iOS Design/Architecture Pattern: Coordinator - Basic

간단한 예제로 살펴보는 iOS Design/Architecture Pattern: Coordinator - Advanced

간단한 예제로 살펴보는 iOS Design/Architecture Pattern: Coordinator - Advanced

 

Coordinator 패턴을 공부하며 알게된 것은 Coordinator가 flow 자체를 관리하도록 설계될 수 있다는 것이다.

이걸 좀 더 명확하게 구분하면 Flow Coordinator로 부르는데,

단순 VC -> VC 화면 이동이 아니라, VC -> 비밀번호 찾기 flow나,

VC -> 사용자 인증 flow 같은 형태로 특정 flow를 거치도록 이동시켜줄 수 있다.

 

앱이 커질수록 특정 flow는 앱 전반에서 재사용이 굉장히 많이 되어야 할 수 있는데 (인증같은 경우 특히)

이때 flow를 재활용하기 용이하게 만들어주는 Flow Coordinator 패턴이 특히 유용할 것이다.

Coordinator 패턴의 대안?

사실 화면 전환 로직을 분리하는 패턴은 Coordinator 패턴만 있는 것이 아니다.

Navigator라는 패턴도 있는데 본질은 동일하다.

VC를 오염시키는 화면 전환 로직을 별도의 객체로 분리하자는 것이다.

개인적으로 인지도는 Coordinator 패턴이 더 높다고 느껴진다.

 

Navigator 패턴 적용 사례는 여기를 참고하자.

GitHub - sergdort/CleanArchitectureRxSwift: Example of Clean Architecture of iOS app using RxSwift

보통 Coordinator 패턴에서 VC 혹은 VM는 Coordinator를 delegate 형태로 weak 참조로 들고 있는 경우가 많다.

따라서 메모리에서 해제되는 것을 막기 위해 Child Coordinator를 배열에 넣어서 자신의 상태로 관리하는 식으로 코드가 구성된다.

 

반면 Navigator 패턴에선 VC 혹은 VM이 각각 Navigator를 강하게 참조하고 있으므로 따로 상태로 navigator를 관리할 필요가 없다.

 

Coordinator 패턴의 장점은 flow 자체를 Coordinator에서 관리할 수 있도록 발전했다는 것이다.

Navigator 패턴은 VC간 이동을 추상화하는 정도에서 그친 것처럼 보인다.

더 공부해볼 것들

Coordinator는 화면 이동을 전담하는 상위 객체이다.

VC에서 의존성 역전을 적용했다면, Coordinator가 VC의 인스턴스화 과정에 필요한 모든 의존성을 주입하는 객체가 될 가능성이 높다.

의존성 주입 DI의 개념과 DI Container 혹은 IOC Container에 대해 더 알아보면 좋겠다.

 

Coordinator 개념에 반응형을 도입한 RxFlow 프레임워크도 공부해보면 좋겠다.

전통적인 Coordinator 패턴에 어떤 문제가 있었고 어떻게 해결했는지를 알아보려면 여기를 참고하자.

RxFlow란

 

추가자료

더 많은 자료를 참고하고 싶다면 https://eunjin3786.tistory.com/441를 방문하자.

[iOS] Coordinator 패턴 글 모음