[iOS] Coordinator Pattern
나는 새로운 개념을 접할 때 뭔가 이걸 사용해서 어떤 문제를 해결하는데 도움이 되고, 왜 사용하는지를 체감했을 때 그 개념을 완전히 받아들일 수 있는 것 같다.
뭔가 내가 이 개념의 필요성을 온전히 느끼지 못하면 사용을 하면서도 마음 한켠에 의문이 작게 자리잡는 것 같다.
그래도 협업을 하고 일을 하기 위해서는 내가 마음으로 완전히 받아들이지 않았음에도 그게 무엇인지 알고 빠르게 받아들일 수 있는 준비는 되어있어야 하는게 맞다고는 생각한다.(근데 그렇게 안했음ㅋㅜ)
이번에 Coordinator Pattern을 처음 공부하게 되었다. 예전에 다른 프로젝트를 통해 개념을 접한 적은 있었지만 그때는 실력이 부족해서 인가 필요성을 온전히 느끼지 못했다.
왜 그랬는지 생각해보면 너무 작은 프로젝트에 이 개념을 도입하다는데 투머치하다는 느낌에 그랬던것 같다.
개인 프로젝트에서 코드를 개선하려고 내 나름 노력하긴 했는데 어떤 개념을 배우고 도입한다기보다 코드를 작성하다가 뭔가 이 방법이 좋지 않은것 같다는 생각이 들면 그때그때 해결방법 찾아가면서 조금씩 기술이나 개념을 도입했었다.
그러나 트랜드라는게 있는 것이고, 필요성을 느끼지 못해도 사람들이 많이 사용한다면 나중에 내가 사용하게 될 순간이 왔을 때 바로 사용할 수 있어야 한다고 생각한다. 아직 많이 부족하니까 우선 배우고 쓸지말지 생각하자!! ^...^
왜 사용할까?
Coordinator Pattern을 공부하기 전 왜 사용하는지가 가장 궁금했다.
결론부터 말하면 화면관리에 대한 추적을 용이하게 하기 위해서다.
VC와 VC를 연결하여 뷰를 차곡차곡 쌓는 과정에서, 작은 프로젝트라면 VC2를 push 하는 방법은 VC1에서 VC2로 가는 경우밖에 없을 가능성이 높다.
하지만 복잡하고 규모가 큰 앱에서는 VC2로 갈 수 있는 방법이 다양할 수 있다.
그렇게 되면 VC2를 호출하는 모든 뷰에서 VC2를 push하는 로직에 접근하게 되고, 작다면 괜찮겠지만 앱이 커질수록 이런 로직을 관리하기 어려울 수 있다.
그리고 Coordinator를 추상화하기 위한 프로토콜을 보는것으로 어떤 동작이 일어나는지, 어떤 뷰가 나타날지 예측할 수 있다.
객체지향 프로그래밍에서 단일 책임 원칙을 생각했을 때 모든 클래스는 하나의 책임을 가져야하지만, 다른 VC를 push 로직이 있다면 이는 다른 뷰에 접근한다는 의미에서 단일 책임 원칙을 위반했다고 볼 수 있을 것 같다.
Coordinator pattern을 처음 접했을 때 뭔지는 알겠는데 이걸 사용해야하는 필요성을 느끼지 못했었다.
그러나 큰 프로젝트에서 Coordinator pattern을 적용한 코드를 보았을 때 화면 전환에 대한 부분을 찾기 위해서 해당 VC의 Coordinator 파일로 가면 된다는 규칙이 생겨 쉽게 코드를 예측할 수 있었다. 굳...
Coordinator Pattern이란?
영어 단어 자체의 뜻으로 보면 어떤 움직임들 관리하는 뉘앙스로 이해할 수 있다.
뜻과 동일하게 Coordinator는 화면전환을 관리하는 역할을 한다.
즉, Coordinator Pattern은 각각의 화면 전환을 담당하는 별도의 Coordinator 객체를 사용하여 앱의 네비게이션 로직을 분리하고 모듈화한다.
기존 프로젝트에서는 MainViewController -> WriteViewController로 이동할 때 MainViewController에서 WriteViewController을 알고 있어야 했다.
private func pushSearchVC() {
let vc = SearchVC(viewModel: self.viewModel)
navigationController?.pushViewController(vc, animated: true)
}
위 코드처럼 보통 뷰를 이동하게 작성했을텐데 그렇게 되면 이 전 VC에서 다음 뷰를 생성하여 pushViewController에 담아주기 때문에 문제가 생겼다고 볼 수 있다.
나는 기존 프로젝트에서 뷰를 이동할 때 뷰 이동하는 부분이 거슬리는(?) 느낌이 있어서 VC파일 제일 하단에 extension으로 빼서 눈에 안들어오게 적었었는데 이 부분을 작성하지 않아도 된다.
Coordinator Pattern을 사용하면 가장 중심이 되는 AppCoordinator를 시작으로 위 그림처럼 트리 형식으로 모든 컨트롤러를 구성할 수 있다.
이렇게 트리형식으로 뷰를 관리하게 된다면 뷰를 제거할 때 상위 Coordinator의 childCoordinator 배열에서 해당 뷰컨트롤러의 Coordinator을 삭제할 수 있어 쌓여있는 뷰에서 중간 뷰에 접근해 뷰를 삭제할 수 있다.
그리고 배열에서 뷰를 제거함으로써 그 뷰에 하위 뷰를 함께 메모리 해제할 수 있어 메모리 관리도 더욱 효율적일 것이다.
처음 공부할 경우 아래 링크의 예제를 직접 따라해보면 빠른 이해 가능!bb