2020-07-18General / Design Pattern

Compound 패턴 (feat. MVC 패턴)

Compound 를 사전에서 찾아보면 복합체, 혼합물 등의 뜻이 나온다.

그렇다면 Compound 패턴은 무엇일까?

Compound 패턴이란?

컴파운드(Compound) 패턴은 이름 그대로 여러 디자인 패턴이 혼합된 디자인 패턴을 말한다.

하지만 단순히 여러 패턴이 사용되었다고 해서 컴파운드 패턴인 것은 아니다.

여러 패턴이 사용되는 동시에 일반적인 문제를 해결하는데 반복적으로 사용될 수 있어야 한다.

Compound Pattern 의 대표적인 예가 바로 그 유명한 MVC Pattern 이다.

MVC 패턴이란?

MVC 패턴의 상호작용

MVC 는 Model-View-Controller 의 약자로서, 역할에 따라 3개의 컴포넌트로 분리하고

여러 디자인 패턴을 적용하여 재사용성을 높인 대표적인 컴파운드 패턴의 예다.

그렇다면 MVC 패턴에서 사용된다는 여러 디자인 패턴은 대체 무엇일까?

전통적인 MVC 패턴에서는 다음 3가지 패턴이 사용된다.

옵저버(Observer) 패턴^[1]
- Model 의 상태가 변경 되었을 때 Controller, 혹은 View 에게 이 사실을 알리는데 사용된다.
컴포지트(Composite) 패턴^[2]
- View 를 구성하는 컴포넌트들은 계층 구조를 이룬다. (e.g. Java Swing 의 JFrame/JLabel 등, Android 의 View/ViewGroup, HTML 의 DOM)
스트래티지(Strategy) 패턴^[3]
- Controller 의 핵심 기능을 인터페이스로 분리하여 View 가 이 인터페이스를 통해 Controller 를 구성(Composition) 한다. 그렇기 때문에 View 는 Controller 를 갈아 끼우며 기능을 변경할 수 있다.

또한, 필요에 따라 어댑터(Adapter) 패턴^[4] 을 함께 사용할 수도 있다.

MVC 패턴은 사용되는 곳에 따라(모바일, 웹 등) 여러 프레임워크에서 다양한 형태로 변형되어 적용되곤 한다.

하지만 이번 섹션에서는 변형되지 않은 전통적인 MVC 패턴에 대해 알아보고, 이어지는 섹션에서 웹 버전의 MVC 인 JSP Model 2 에 대해 알아본다.

그렇다면 전통적인 MVC 의 3가지 컴포넌트에 대해 알아보자.

모델(Model)

Model 은 애플리케이션의 핵심 로직과 데이터를 가지고 있는 컴포넌트다.

Controller 가 Model 에게 상태 변경을 요청하면 Model 은 일련의 과정을 거쳐 자신의 상태를 변경하게 되고

상태 변경이 완료되면 이를 Controller 와 View 에게 알린다.

그런데 Model 의 한가지 큰 특징은 Controller 와 View 에 대해 알지 못한다는 것이다.

이게 가능한 이유는 위에서 언급한 것처럼 Observer 패턴을 사용하기 때문인데

조금 설명을 하자면, Controller 와 View 는 Observer 라는 인터페이스를 구현하고

이 타입을 통해 Model 을 subscribe 하므로 Model 입장에서 이들은

단순히 모두 똑같은 Observer 일 뿐이지 각 Observer 가 실제로 어떤 객체인지는 알 필요가 없다.

클래스 다이어그램을 그려보면 다음과 같다

MVC 패턴의 클래스 다이어그램

이를 통해 Controller 와 View 에 대한 Model 의 결합(Coupling)을 느슨하게 하고, 이들의 재사용성을 높이게 된다.

참고로, 전혀 다른 비즈니스 로직을 가지는 Model 에 Adapter 패턴을 활용하여 기존의 View 와 Controller 를 그대로 재사용할 수도 있다.

뷰(View)

View 는 사용자와의 상호작용을 담당하며, 크게 2가지 역할을 수행한다.

첫째는 사용자에게 화면을 보여주는 것이다. GUI 환경이라면 버튼이나 체크박스 등이 될 수 있고, CLI 환경이라면 텍스트가 될 것이다.

Model 로 부터 자신의 상태가 변경 되었다는 알림을 받을 때마다 Model 에게 데이터를 받아, 이를 기반으로 화면을 업데이트한다.

Model 의 데이터를 기반으로 변경하는 것 뿐만 아니라, 단순히 Controller 요청에 따라 화면을 변경하기도 한다.

둘째는 사용자의 입력 이벤트를 받는 것이다. 정확히는 사용자의 이벤트를 받아 Controller 에게 전달한다.

컨트롤러(Controller)

Controller 는 View 와 Model 사이의 중재자이다.

Controller 는 View 로 부터 사용자의 입력 이벤트를 받으면 다시 View 에게 화면 업데이트를 요청할 수도 있고

Model 에게 상태 변경을 요청할 수도 있다. 위에서 말한 것처럼 Model 은 상태 변경이 완료되면 Observer 패턴을 통해 Controller 와 View 에게 이를 알린다.

JSP Model 2 란?

JSP Model 2 의 구조 (출처: https://en.wikipedia.org/wiki/JSP_model_2_architecture)

JSP Model 2^[5] 란 MVC 패턴을 웹 애플리케이션에 맞는 형태로 적용시킨 것이다.

즉, Spring 과 같은 Web Framework 에서 사용하는 MVC 패턴은 JSP 를 사용하지 않는다고 하더라도

사실상 전통적인 MVC 패턴 보다는 이 JSP Model 2 에 해당한다고 할 수 있다.

(좀 더 구체적으로 말하자면, Spring MVC 에서 사용하는 패턴은 Servlet(DispatcherServlet)에서 HTTP 요청을 처리하는 것을 제외한 Controller 로직을 분리한 구조로, Front Controller 패턴^[6] 이라고 부른다.)

사실 JSP Model 1^[7] 도 있는데 Model 1 에서는 View 와 Controller 의 역할이 분리되지 않고 하나의 컴포넌트에서 담당하는 모양을 하고있다.

Model 2 의 등장으로 웹 애플리케이션 개발 단위는 View 에 해당하는 JSP pages 와 Controller 에 해당하는 Servlet 이 완벽하게 분리되었기 때문에 HTML 과 약간의 JSP 에 대한 지식을 가진 웹 퍼블리셔와 전문적인 소프트웨어 지식을 가진 개발자의 역할을 분리하여 생산성을 높이는데 기여했다.

그럼 Model 2 에서는 MVC 의 각각의 컴포넌트가 전통적인 MVC 와 어떻게 다른지 알아보자

Java Bean (Model)

Model 2 에서의 Model 이 전통적인 MVC 에서의 Model 과 가장 큰 차이점은

Model 2 에서는 View 로 부터 사용자의 입력 이벤트가 들어올 때, 네트워크(HTTP)를 통해 들어온다는 것이다.

그렇기 때문에 Model 의 상태 변경이 완료되었을 때 View 에게 이를 알리지 않는다.

단지 Controller 의 요청이 있을 때만 Model 이 Java Bean 으로서 Controller 를 통해 View 에게 전달될 뿐이다.

JSP (View)

Controller 를 통해 Model 로 부터 전달받은 Java Bean 내 데이터를 기반으로 화면을 구성한다.

Servlet (Controller)

HTTP 요청에 따라 Model 에 상태 변경을 요청하고 상태가 변경된 Model 을 View 에 전달한다.

HTTPServlet 클래스를 상속받아 doGet(), doPost(), doPut(), doDelete() 등의 메소드를 Override 하여

HTTP 요청을 받으며, 메소드 인자로 전달된 HttpServletRequest 객체를 사용하여 요청과 함께 전달된 데이터를 읽어들인다.

참고

https://github.com/sgc109/design-pattern-study
Head First Design Patterns
JavaServer Pages Spec

#Design Pattern