1. Coordinator 어떻게 알게 되었냐?

때는.. 올해 7~8월 저는 개발을 시작한지 10개월정도만에 MVC 패턴에서 벗어나서 MVVM 패턴으로 코딩을 하기 시작했습니다. 제가 작성한 더럽고 지저분한 ViewController의 코드에서 비즈니스 로직이 ViewModel로 넘어가는 것을 보면서 희열을 느꼈는데요! 문득 궁금증이 생겼습니다

<aside> ❓ 화면이동 로직이 굳이..VC가 해야되나?

</aside>

그렇게 처음 Coordinator에 대해서 알게 되었지만, ZOOC 프로젝트에 바로 적용하기에는 너무 대공사여서 개념만 공부하고 나중을 기약하며 안녕~ 했는데요…

다시 만난 너..

이번에 솝트 과제 날씨 앱을 Tuist로 세팅을 하면서 가장 큰 장점은 모듈의 의존성을 신경쓰면서 개발을 하게 된것입니다. 근데 MainVC에서 DetailVC로 화면이동 코드를 작성하기 위해서 의존성에 어긋나게 Detail Feature 모듈의 import를 해야하는 상황이 생겼기 무조건 고쳐야겠다고 생각했습니다. 그래서 이참에 공부를 하고 적용해야겠다고 느꼈습니다.

2. Coordinator 패턴?

ViewController가 보유하던 책임 중 Navigation과 관련된 부분을 다른 인스턴스에서 책임지도록 하는 패턴

why? → 기존 방식의 문제점

Khanlou : Massive View Controller의 가장 큰 문제 중 하나는 flow logic(흐름 로직) 및 business logic이 얽혀있다는 것이다!

우리가 많이 사용하는 방식은 아래와 같은 코드로 이루어진 형태죠?

하지만 여기서 가장 큰 문제점은 기존의 뷰컨이 다음 띄어질 뷰컨을 알고 있어서 ViewController **인스턴스 간에 심한 커플링**이 생길 수 있다는 겁니다.

커플링: 두 오브젝트가 잘 알고 지내고 하드하게 연결되어 있는 정도

즉 강한 결합도를 지니게 되면 좋지 않겠죠? + 뷰컨간의 의존성도 생겨버립니다 ㅠ

private func pushToWelcomeView() {
        let welcomeViewController = OnboardingWelcomeViewController()
        self.navigationController?.pushViewController(welcomeViewController, animated: true)
    }

제가 느낀 가장 문제가 된다고 생각했던 두가지는

1. 특정 VC에서 다른 VC를 알고 있어야 한다는 부분

   → 이게 특정 모듈이 다른 모듈을 알고 있다는 부분으로 확장될수록 더 말이 안되는..

2. Massive ViewController의 원인이 됩니다. → 화면 로직이 많아질수록 VC의 역할이 커지고 당연히 SOLID 원칙을 지키지 못하겠죠