디자인 패턴 - Compound Pattern

Compound Pattern이란?

컴파운드 패턴은 이름 그대로 여러 디자인 패턴이 혼합된 디자인 패턴을 말함. 일련의 패턴을 함께 사용하여 다양한 디자인 문제를 해결함. 반복적으로 생길수 있는 일반적인 문제를 해결하기 위한 용도로 사용됨. 패턴으로 이루어진 패턴. / 하지만 단순히 여러 패턴이 사용되었다고 해서 컴파운드 패턴인 것은 아님. 앞서 말했듯 여러 패턴이 사용되는 동시에 일반적인 문제를 해결하는데 반복적으로 사용될 수 있어야 함. Compound Pattern의 대표적인 예시는 그 유명한 MVC Pattern.

 

MVC Pattern이란?

MVC(Model-View-Controller) Pattern은 하나의 application, project를 구성할 때, 그 구성요소를 역할에 따라 모델-뷰-컨트롤러라는 세 가지 역할로 구분한 패턴. 여러 디자인 패턴을 적용하여 재사용성을 높인 대표적인 컴파운드 패턴의 예. 

 

ㆍModel - 애플리케이션의 데이터, 자료를 의미 / Data storage, integrity, consistency, queries and mutations / 프로그램에 사용되는 데이터를 의미하며 데이터베이스, 상수, 문자열과 같은 변수들, vision 프로그램이라면 카메라 정보와 같은 것들이 해당됨. 모델에는 View와 Controller의 정보가 전혀 없음. 단지, 정보만 반환하거나 설정할 수 있음. / 애플리케이션의 핵심 로직과 데이터를 가지고 있는 컴포넌트 / Controller가 Model에게 상태 변경을 요청하면 Model은 일련의 과정을 거쳐 자신의 상태를 변경하게 되고 상태 변경이 완료되면 이를 Controller와 View에게 알림. 여기서 큰 특징이 Controller와 View에 대해 알지 못한다는 것. 이게 가능한 이유는 Observer Pattern을 사용하기 때문. Controller와 View는 Observer라는 인터페이스를 구현하고 이 타입을 통해 Model을 subscribe 하므로 Model 입장에서 이들은 단순히 모두 똑같은 Observer일 뿐임. 각 Observer가 실제로 어떤 객체인지 알 필요 없음. / Controller와 View에 대한 Model의 결합(Coupling)을 느슨하게 하고, 이들의 재사용성을 높이게 됨. / 전혀 다른 비즈니스 로직을 가지는 Model에 Adapter Pattern을 활용하여 기존의 View와 Controller를 그대로 재사용 할 수도 있음.

- Model이 가진 규칙 : 사용자가 편집하기를 원하는 모든 데이터를 가지고 있어야 함. / View나 Controller에 대해서 어떠한 정보도 알지 말아야 함. / 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야만 함.

 

ㆍView - 사용자에게 보여지는 부분, 즉 UI를 의미 / presentation assets and code / Dialog에 존재하는 TextBox, Label, Button 등 사용자 인터페이스(User Interface) 요소들을 의미함. 사용자가 제어하고 확인할 수 있는 영역. 뷰에서는 별도의 데이터를 보관하지 않음. 뷰에서 입력받고 출력해주는 모든 데이터는 Model을 사용해야 함. / 사용자와의 상호작용을 담당하며 크게 2가지 역할 수행. 첫째는 사용자에게 화면을 보여주는 것. Model로 부터 자신의 상태가 변경되었다는 알림을 받을 때마다 Model에게 데이터를 받아, 이를 기반으로 화면을 업데이트함. Model의 데이터를 기반으로 변경하는 것 뿐만이 아니라 Controller의 요청에 따라 화면을 변경하기도 함. 둘째는 사용자의 입력 이벤트를 받는 것. 사용자의 이벤트를 받아 Controller에게 전달.

- View가 가진 규칙 : Model이 가지고 있는 정보를 따로 저장해서는 안됨. / Model이나 Controller와 같이 다른 구성요소들을 몰라야 됨. / 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야 함.

 

ㆍController - Model과 View 사이를 이어주는 브릿지(Bridge) 역할을 의미 / receive, interpret and validate input. create and update views. query and modify models / Model과 View를 관장하는 브릿지 역할을 수행함. 사용자가 버튼을 클릭하면 이벤트는 View에서 발생하지만 내부 처리는 Controller에서 관리하는 것임. 또한, 입력이 발생하면 이에 대한 통지를 담당함. / View와 Model 사이의 중재자. Controller는 View로부터 사용자의 입력 이벤트를 받으면 다시 View에게 화면 업데이트를 요청할 수도 있고 Model에게 상태 변경을 요청할 수도 있음. 앞에서 말한것처럼 Model은 상태 변경이 완료되면 Observer 패턴을 통해 Controller와 View에게 이를 알림.

- Controller가 가진 규칙 : Model이나 View에 대해서 알고 있어야 함. / Model이나 View의 변경을 모니터링 해야 함.

 

Controller ->   화면 업데이트 요청   -> View -> 상태 정보 받아옴 -> Model -> 상태 변경 완료 알림 -> Controller 

      C <- 사용자 입력 이벤트 전달 <-  V   <- 상태 변경완료 알림  <-  M  <-  상태 변경요청, 상태정보 받아옴 <-  C

 

▶전통적인 MVC 패턴에서 사용되는 3가지 패턴

ㆍStrategy Pattern : 뷰와 컨트롤러는 고전적인 스트레티지 패턴으로 구현되어 있음. 컨트롤러가 전략을 제공하고, 뷰 객체를 여러 전략을 써서 설정할 수 있음. Strategy Pattern을 사용하는 것은 뷰를 모델로부터 분리시키는 데에도 도움이 됨. 사용자가 요청한 내역을 처리하기 위해서는 모델과 얘기를 해야하는데 그 부분은 컨트롤러가 담당. 뷰는 그 방법을 알지 못함. 뷰에서는 애플리케이션의 UI에만 신경을 쓰고, 인터페이스의 행동에 대한 결정은 모두 컨트롤러에게 맡김. (사용자의 요청을 컨트롤러로 넘김). 컨트롤러는 뷰 객체의 전략 객체에 해당함. 사용자의 행동에 따라 어떤 행동을 취해야 할지를 알고 있음. 컨트롤러를 바꾸면 뷰의 행동을 바꿀수 있음. / Controller의 핵심 기능을 인터페이스로 분리하여 View가 이 인터페이스를 통해 Controller를 구성함. 그렇기 때문에 View는 Controller를 갈아 끼우며 기능을 변경할 수 있음.

ㆍComposite Pattern : 뷰는 GUI 구성요소(윈도우, 패널, 버튼, 레이블, 텍스트 항목 등)들로 구성된 복합 객체임. 최상위 구성요소에는 다른 구성요소들이 들어있고, 그 안에는 또 다시 각각 다른 구성요소들이 들어갈 수 있음. 컨트롤러에서 뷰한테 화면을 갱신해 달라고 요청하면 최상위 뷰 구성요소한테만 화면을 갱신하라고 전달하면 됨. 나머지는 컴포지트 패턴에 의해 자동으로 처리됨. / View를 구성하는 컴포넌트들은 계층구조를 이룸 (Java Swing의 JFrame/JLabel, Android의 View/ViewGroup, Html의 DOM 등)

ㆍObserver Pattern : 모델에서는 옵저버 패턴을 사용하여 상태가 변경되었을때 그 모델하고 연관된 객체들에게 연락을 함. 옵저버 패턴을 사용하면 모델을 뷰 및 컨트롤러로부터 완전히 독립시킬 수 있음. 한 모델에서 서로 다른 뷰를 사용할 수도 있고, 여러개의 뷰를 동시에 사용할 수도 있음. 모델의 상태 변화에 관심이 있는 객체라면 어떤 객체든지 모델에 옵저버로 등록할 수 있음. 모델의 상태가 변경될 때마다 모든 옵저버들한테 연락이 전달됨. 모델은 뷰나 컨트롤러에게 전혀 의존하지 않음. 

- 필요에 따라 Adapter Pattern을 함께 사용할 수도 있음. 

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

 

MVC와 Web environment

ㆍJSP Model 2 : 웹에서 MVC를 브라우저나 서버 모델에 맞게 변형시켜서 사용하는 방법 중 하나 / MVC 패턴을 웹 애플리케이션에 맞는 형태로 적용시킨 것. 즉, Spring같은 Web Framework에서 사용하는 MVC 패턴은 JSP를 사용하지 않더라도 사실상 전통적인 MVC 패턴보다는 이 JSP Model 2에 해당한다고 할 수 있음. (Spring MVC에서 사용하는 패턴은 Servlet에서 HTTP 요청을 처리하는 것을 제외한 Controller 로직을 분리한 구조로, Front Controller 패턴이라한다 함) 

① 사용자가 HTTP 요청을 하면 서블릿에서 요청 수신 - 사용자가 웹 브라우저를 써서 HTTP요청을 함. 이때 보통 사용자 ID와 비밀번호같은 폼 데이터가 함께 전달됨. 서블릿에서는 이런 폼 데이터를 받아서 파싱함.

② 서블릿이 컨트롤러 역할을 함. - 서블릿은 컨트롤러 역할을 맡아서 사용자 요청을 처리하고, 대부분의 경우에 모델(보통 데이터 베이스)에 어떤 요청을 하게 됨. 요청을 처리한 결과는 일반적으로 자바 빈 형태로 포장됨.

③ 컨트롤러에서는 컨트롤을 뷰한테 넘김 - 뷰는 JSP에 의해 표현됨.

④ 자바 빈을 통해 얻은 모델의 뷰를 나타내는 페이지만 만들어주면 됨. 물론 그 페이지를 만드는 과정에서 다음 단계의 작업을 위해 몇가지 더 제어해야할 일이 있을 수 있음.

⑤ 뷰에서 HTTP를 통해서 브라우저한테 페이지 전달 - 페이지가 브라우저한테 전달되며, 그 웹 페이지가 사용자의 화면에 표시됨. 사용자가 또 다른 요청을 할수도 있으며, 새로운 요청도 지금까지의 방식과 같게 처리됨.

- Model 2가 등장하면서 개발자들은 서블릿에만 전념하면 되고, 웹 제작자들은 간단한 Model 2 스타일의 JSP만 다루면 되는 환경이 조성됨. 그래서 웹 제작자들은 HTML과 간단한 자바 빈즈만 다루면 된다함.

- JSP Model 1도 있는데 Model 1에서는 View와 Controller의 역할이 분리되지 않고 하나의 컴포넌트에서 담당하는 모양을 함. 

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

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 객체를 사용하여 요청과 함께 전달된 데이터를 읽어들임.

 

디자인 패턴으로 본 Model 2

Observer Pattern - 고전적인 의미에서 뷰는 더 이상 모델의 옵저버라고 할 수 없음. 모델한테 등록해서 모델의 상태가 바뀌었다는 연락을 받는다거나 하지 않기 때문. 하지만 여전히 모델의 상태가 바뀔때 컨트롤러를 통해서 간접적으로나마 연락을 받음. 그리고 컨트롤러에서는 뷰한테 Bean을 건네주기 때문에 뷰에서 모델의 상태를 알아낼 수 있음. / 브라우저 모델의 입장에서, 뷰에서는 브라우저로 HTTP 응답을 할때만 모델의 상태에 대한 정보가 필요함.

Strategy Pattern - Model 2에서도 컨트롤러 서블릿이 여전히 전략 객체로 사용됨. 하지만 고전적인 MVC처럼 뷰 객체에 컨트롤러 객체에 대한 래퍼런스가 들어가는 방식으로 구현되진 않음.

Composite Pattern - Swing GUI처럼 여기에서 쓰이는 뷰도 중첩된 그래픽 구성요소로 이루어짐. 이 경우에는 HTML코드를 통해서 웹 브라우저에서 랜더링 된다는 차이점이 있긴 하지만, 그 밑에는 결국 복합 객체 형태의 객체 시스템이 있을 가능성이 높음.