MVC 패턴의 본질
이 부분에 대해서는 나도 고민이 많았고, 커뮤니티에서도 토론이 활발했다. 다들 MVC, MVC 이야기하는데 이걸 쓰면 좋은 건가? 에 대한 납득이 되지 않았나 보다. 그래서 나 또한 무지성으로 패턴을 사용하기보다 스스로 납득 가능한 이유를 찾기로 했다.
우선 MVC의 본질부터 알아보고자 했다. 이 MVC라는 개념이 어떻게 등장했는지를 알면 그에 맞게 쓸 수 있을 것 같아서다. (참고: MVC 창시자가 말하는, MVC의 본질) 앨런 케이가 창시한 객체 지향 프로그래밍(Object oriented Programming)은 다음과 같은 고민에서 시작되었다고 한다.
좋은 코드를 만들기 위해서
어떤 방식으로 코드를 나누고 묶어줘야 할까?
어떤 방식으로 코드를 추상화해야 할까?
여기에 더해, 트라이브라는 사람은 (1) 비즈니스 로직과 (2) 시각적인 UI, 그리고 (3) 둘 사이를 연결해 주는 부분을 코드 안에서 분리하고 역할 부여를 해줘야 한다는 생각을 했다는데, 이 두 사람의 말을 듣고 보니 MVC 패턴이 해결하고자 하는 문제를 조금은 알 수 있었다.
곧, MVC의 본질은 관심사의 분리인 것이다. 좋은 코드를 만들기 위해 코드 혹은 모듈의 역할을 나누고, 각자 역할에 따라서 움직이며, 서로가 서로에게 영향을 받지 않고 코드의 중복을 줄일 수 있다. 이렇게 되면 유지보수도 편하고, 좋은 코드라고 할 수 있는 것에 가까워진다.
참고한 글에서도 말하는 듯이, 사실 객체지향이든 절차지향이든 MVC 패턴이든, 어쨌든 목적은 하나다. 유지보수하기 편하고 읽기 쉬운 코드를 작성하기 위한 수단이다.
MVC 패턴 적용
이렇듯 본질과 목적에 대해 이해하고 나니 MVC 패턴을 적용하기가 수월해졌다. 그리고 지난 1주 차 미션에서 아쉬웠던 관심사 분리를 MVC 패턴을 통해 적용하면서 각 폴더와 코드들의 목적을 더 잘 파악하기 쉬웠다. 나는 아래와 같이 MVC 패턴을 적용해 보았다.
MVC @InterviewBit
우선 전체적인 로직은 사용자 요청이 들어오면 → Controller가 중재자 역할을 하고 → View로 사용자 요청을 받아서 → Model을 생성하여 로직을 처리한다. → 그리고 다시 Controller라는 중재자가 View로 사용자에게 응답을 주도록 설계했다. 이 중 Model(Car.js)에서는 각 자동차들의 데이터 (name, position)을 저장했다. 여기서 자동차라는 객체를 만드는 필드는 이름이라는 속성이 있고, Car만이 가지는 '달린다'라는 고유한 동작을 정의했다.
View는 사용자가 자동차 이름과 시도 횟수를 입력하고 검사하는 inputView와, 사용자에게 결과 값을 출력하는 outputView로 구성했다. 마지막으로 Controller는 위의 Model과 View 사이에서 비즈니스(도메인) 로직을 처리하도록 컨트롤 타워의 역할을 하게 했다.