MVC든 MVVM이든, 비즈니스 로직과 flow logic이 혼재되어있는 문제가 있다.
flow logic이 특정 뷰(혹은 뷰컨)에 속하면 안되는 이유는 무엇일까?
위와 같은 문제를 해결하려면 flow 로직이 뷰/뷰컨 객체로부터 분리되어야 한다.
이러한 필요성에 따라 모든 ViewController를 모아 관리하는 높은 수준의 객체(Coordinator)를 두어 flow logic을 담당하도록 하는 것이 Coordinator Pattern이다.
Coordinator 패턴은 KHANLOU의 The Coordinator 포스팅에서 처음 제안되었다고 한다.
AppDelegate 혹은 SceneDelegate와 같은 엔트리포인트는 앱의 flow를 관장하는 App(Scene)Coordinator를 유지하며, 모든 Coordinator는 하위 Coordinator(들)를 소유한다.
childCoordinator(들)를 부모 coordinator가 소유하는 이유는, childCoordinator들의 사용이 완전히 끝나기 전까지 메모리에서 할당 해제되지 않도록 보장하기 위함이다.
뷰 컨트롤러는 데이터를 표시하는 방법 외에는 아무것도 모릅니다. 어떤 일이 발생할 때마다 대리인에게 알리지만 물론 대리인이 누구인지는 모릅니다.
한 번에 두 개의 흐름이 필요한 경우 뷰 컨트롤러 전체에 많은 조건문을 붙이는 대신 전체 코디네이터 개체를 교체할 수 있습니다.
흐름이 작동하는 방식을 이해하고 싶다면 모든 코드가 한 곳에 있기 때문에 매우 쉽습니다.
그들은 어떤 컨텍스트에서 표시될 것인지 또는 버튼이 무엇을 위해 사용될 것인지에 대해 아무 것도 가정하지 않습니다. 논리를 끌어들이지 않고도 보기 좋게 사용하고 재사용할 수 있습니다.
앱의 iPad 버전을 작성하는 경우 교체해야 하는 유일한 것은 코디네이터이며 모든 컨트롤러를 재사용할 수 있습니다.
작업이 여러 뷰 컨트롤러에서 작동하더라도 캡슐화됩니다. iPad 버전에서 이러한 하위 작업 중 일부는 재사용하지만 나머지는 재사용하지 않는 경우 해당 하위 작업만 사용하기가 정말 쉽습니다.
뷰 컨트롤러를 present할 때 뷰 컨트롤러가 데이터를 엉망으로 만들지 다시 걱정할 필요가 없습니다. 읽기 및 표시만 할 수 있으며 데이터를 쓰거나 손상시키지 않습니다.
당신은 작업을 위해 -viewDidLoad의 호출을 기다리지 않고도 뷰를 완전히 통제할 수 있습니다. UIViewController당신이 이해할 수 없는 마법을 부리는 슈퍼클래스의 보이지 않는 코드 가 없습니다. 이 모델을 뒤집으면 무슨 일이 일어나고 있는지 훨씬 더 쉽게 이해할 수 있습니다. 앱의 동작은 완전히 투명하며 UIKit이제는 사용하고 싶을 때 호출하는 라이브러리일 뿐입니다.
자료 출처: KHANLOU - The Coordinator, Coordinators Redux
참고: Coordinator Pattern. Coordinator의 시작부터 간단한 사용까지 | by Zedd | Medium
Coordinator Pattern으로 앱의 flow를 관리하면 앱의 흐름을 follow하기 위해서 우리는 더이상 뷰컨트롤러나 뷰모델을 구석구석 찾을 필요가 없다. Flow에 관한 모든 코드는 부모-자식coordinator 객체 트리에서 찾을 수 있을 것이며, ViewController들은 뼈대를 이루는 Coordinator 트리의 부수적인 요소가 될 뿐, flow에 영향을 미치지 않게 된다. Zedd님이 포스팅 말미에 언급하신 것처럼, Ribs로 이행하기 이전의 중간단계처럼 느껴지기도 한다.