[Coordinator] The Coordinator

Coordinator pattern이 왜 궁금해졌냐면 ...

얼마 전에 회사 앱 구조를 변경하는 과정에서 기존 flow 로직을 수정하는 일이 있었다.

 

그러면서 동일한 view controller가 어떤 상황에서는 NavigationController의 child로 push 될 때도 있고 어떤 상황에서는 단일 ViewController로 present 되는 상황이 생기면서 단순히 dismiss로 처리하던 flow 로직이 상황에 따라 다르게 처리돼야하는 상황도 생겨버리고 말았다 ....!

 

심지어 이러한 flow logic이 view controller 내부에 자리를 잡고 있어서

1) view controller가 다음에 present해야하는 view controller를 알고 있게 되거나(심지어 상황에 따라 어떤 view controller를 띄워야하는지 이러한 로직을 다 알고 있어야했다 ...)
2) back button을 클릭하는 경우, navigation controller가 존재하는지 확인 후 pop / dismiss 중 로직을 선택하는 등
view controller가 너무 많은 책임을 지게 되는 동시에 너무 많은 것을 알게 되는 현상이 발생했다...🔫

 

계속 이런 식으로 개발을 하다가는 나중에 너무 골치 아파질게 뻔해서(이미 골치아픔...🫠) 어떻게 개선할 수 있을까 고민하다가 Coordinator Pattern이 생각났다. 아직 한 번도 안써봤지만 ... 옛날에 새싹 과정 진행할 때 MVVM-C 패턴 적용해서 프로젝트 하던 동기들도 생각나구 ...? 립스 쓸 때는 라우터에서 이런 처리를 다 해줘서 참 편했는데...coordinator pattern이 그 역할을 해줄 것 같고,, 이 기회에 한 번 공부해보면 좋겠다 ! 싶어서 공부 시작... =33

(최종적으로 회사 코드에 적용할 수 있을지는 모르겠지만 그래도 공부하는 것에 의의를 두고자...^_^)

 

Coordinator pattern에 대해 검색하다보니 다들 2015년에 작성된 아래의 블로그 글로부터 coordinator pattern이 파생되었다하여 원본부터 번역해보기로 =33

The Coordinator 🔗

Big ViewController들의 가장 큰 문제점 중 하나는 flow logic, view logic, business logic이 모두 엮여있다는 것이다.

 

Tableview Cell을 선택했을 때 delegate 로직은 보통 다음과 같은 메소드를 호출하게 된다.

override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    let object = self.dataSource.object(at: indexPath)
    let detailViewController = SKDetailViewController(detailObject: object)
    self.navigationController?.present(detailViewController, animated: true)
}

 

여기에는 3가지 로직이 들어있다.

1) get the object(dataSource로부터 필요한 object 가져오기)

2) create a view controller(위에서 가져온 object로 view controller 생성하기)

3) present the view controller(해당 view controller present하기)

 

간단한 앱에서는 이러한 view controller가 하나의 상황에서 한번만 사용되기 때문에 이런 식으로 구현을 해도 문제점이 없다. 하지만 앱이 복잡해질 수록 동일한 view controller가 재사용될 가능성이 높아진다. 

 

만약 위의 코드와 같이 flow logic이 내부에 작성될 경우, view controller는 재사용하기가 어려워진다. 그리고 view controller의 base class는 UI로 시작한다는 사실을 잊지말 것….^^ view 객체이기 때문에 user flow까지 컨트롤하는 것은 범위 외의 일이라고 생각한다.

 

위의 코드를 보면 이 view controller는 다음 flow를 위한 것을 어떻게 만들어야하는지, 그것을 어떻게 present할것인지를 다 알고 있다. 그리고 3번째 줄을 보면 부모 view controller에게 ~~~~을 하세요! 라고 일을 시키고 있죠? 완전 역순이죠? 그리고 더 최악인건 flow code가 여러 view controller과 엮여있다는 것 … (현재 view controller, 부모, present하고자 하는 view controller..)

 

따라서 View Controller들은 더 상위 개념의 객체들로 하여금 정리하고 관리되는 모습이 맞다고 생각한다.

이때 그 객체를 Coordinator라고 부른다. (혹은 Directors)

이러한 개념의 구현은 AppDelegate가 최상단의 Coordinator라고 볼 수 있는 AppCoordiantor를 들고 있고 이때 각 Coordinator들은 자신의 child coordinator들의 배열을 갖고 있는 모습으로 보여진다. 그리고 특히 탭바처럼 하나 이상의 navigation controller를 갖고 있는 경우에는 각 navigationController가 자기 자신의 coordinator를 갖게 된다. 또한 가입, 콘텐츠 생성과 같은 특정 작업을 위해 추가적으로 child coordinator도 생성할 수 있다. (여기서 궁금해진 것... Coordinator를 생성하는 기준은 어떻게 정하면 좋을지...? 🤔) 이때 모든 coordinator은 자신의 parent coordinator로부터 생성된다는 점 !!

 

Coordinator는 PONSO다. (Plain Old NSObjects라고 하네요)

PONSO가 뭔가 했더니 Plain Old NSObjects의 줄임말이다.

Plain Old xxObjects라는 용어가 있는 것 같은데 낯설어서 찾아보니 주로 Java에서 사용되는 용어인듯한데 특정 기술에 의존하지 않고 본래 자바의 장점을 살리는 '오래된' 방식의 '순수한' 자바객체를 의미한다. 🤔 

그럼 PONSO 또한 NSObject의 특징을 살리는 단순하고 범용적인 기능을 제공하는 객체를 의미하는거겠지 ... ?!

 

예를 들어서 인스타그램의 photo creation 과정을 하나의 coordinator로 생성할 수 있을 것 같다. 

여기서 child coordinator인 PhotoCreationCoordinator를 생성할 때 rootViewController를 전달하여 flow를 진행할 수 있도록 하고 있다.

// create a new photo selection viewcontroller & configure it
func beginPhotoCreationProcess() {
    // 여기서 coordinator로 하여금 photo selection view controller의 delegate를 채택하게해서 다음 스텝을 보여줘야하는 시간이 됐을 때 informed되게함!
    // 이 과정에서 viewcontroller들은 서로에 대해 전혀 알 필요가 없음!! 각 view controller는 섬이다..라고 생각하자 ㅎ_ㅋ
    let coordinator = PhotoCreationCoordinator(rootViewController: self.rootViewController, delegate: self)
    self.childCoordinators.append(coordinator)
    coordinator.beginPhotoCreationProcess()
}

func photoCreationCompletedSuccessfully(_ coordinator: PhotoCreationCoordinator) {
    if let index = self.childCoordinators.firstIndex(where: { $0 === coordinator }) {
        self.childCoordinators.remove(at: index)
    }
}

func photoCreationCanceled(_ coordinator: PhotoCreationCoordinator) {
    if let index = self.childCoordinators.firstIndex(where: { $0 === coordinator }) {
        self.childCoordinators.remove(at: index)
    }
}

 

비즈니스 로직(ex. posting the photo)는 coordinator 혹은 model로 이동시킬 수 있는데 어느 쪽으로 이동하든 둘 다 view controller 외부로 빠져나오는거라고 볼 수 있다. 코디네이터로 비즈니스 로직을 이동시키는걸 추천하는데 왜냐면 코디네이터가 이미 코드의 다른 부분 사이의 접착제 역할을 하고 있기 때문이다.

 

이렇게 flow layout을 분리시키는 것은 여러 장점을 가지고 있는데 ...

view controller는 model을 view에 바인딩시키는 역할에 집중할 수 있다. 또한 쉽게 재사용될 수 있으며 다양한 상황에서 복잡한 조건문 없이 사용될 수 있다.

View controller의 초기화 또한 분리될 수 있다. Initializing은 생각보다 복잡한 작업이기 때문에 이를 간과해서는 안된다. 

 

애플은 view controller로 하여금 iOS 세계의 중심이 되길 원하지만 그러한 모습은 앱의 확장 가능성을 지원한다고 보기 어렵다 .. 이를 개선하기 위해 사용되는 Coordinator는 코드를 쉽게 교체할 수 있는 단위로 분리할 수 있는 좋은 방법이다. 

---

내가 처음에 필요하다고 생각했던 배경과 coordinator pattern의 목적이 부합하는 듯 하여 조금 더 알아봐야할 것 같다!

개념적인 내용은 이해완...🫡 

다음 글에서 조금 더 구현과 가까운 이야기를 하고 있다고 하니 추후에 더 자세히 알아봐야겟따