[헤드퍼스트 디자인패턴] 42일차. 554-564pg | MVC패턴

42일차

헤드퍼스트 디자인패턴 [7주차_토요일]
554-564pg

요약

 

**CHAPTER 12. 패턴을 모아 패턴 만들기 (feat. 복합 패턴)**

여러 패턴을 함께 사용하면 더욱 강력한 객체지향 디자인을 만들 수 있다. 패턴 활용법을 한 단계 끌어올려 줄 복합 패턴

 

[ 복합패턴의 왕 - MVC ]

- MVC는 코드를 기능에 따라 나눠 주는 패러다임

- 모델 객체는 애플리케이션 존재의 의미. 데이터, 놀리 같은 게 전부 들어 있는 객체

그 클래스는 애플리케이션의 문제를 해결하는 클래스

어떤 뷰에서도 재사용 가능

뷰가 바뀌어도 모델 객체는 그대로 남는다.

 

- 뷰 객체는 표시하고 편집하는 컨트롤.

코코아(MacOS에서 쓰이는 애플리케이션 제작용 프레임 워크)에는 훌륭한 컨트롤이 많다.

연결은 느슨하게 재사용을 끌어올리는 것이 좋다.

 

- 데이터는 모델과 뷰 사이에서 움직인다. 컨트롤러는 둘 사이의 중계자. 각 계층의 상태가 바뀔 때면 그 둘의 데이터를 동기화한다.

 

- 컨트롤러는 모델과 뷰 모두하고 친하다.

재사용의 가장 큰 적, 하드코딩도 종종 쓴다. 하지만 모델 키를 어떤 뷰 속성에도 마음대로 연결할 수 있다.

 

- MVC를 배울 때 일단 여러 패턴을 합쳐 놓았다는 사실을 가장 먼저 이해하면 된다.

 

 

[ 모델 - 뷰 - 컨트롤러 ]

뷰 --뷰 디스플레이 갱신--> 사용자 -- 인터페이스 건드림--> 컨트롤러 --컨트롤러에서 모델을 조작 --상태 변화 통지 --> 뷰 >

 

[ 뷰 View ]

- 모델을 표현하는 방법을 제공한다.

- 일반적으로 화면에 표시할 떄 필요한 상태와 데이터는 모델에서 직접 가져온다.

 

[ 컨트롤러 Controller ]

- 사용자로부터 입력을 받으며 입력받은 내용이 모델에게 어떤 의미가 있는지 파악한다.

 

[ 모델 Model ]

- 모델에는 모든 데이터, 상태와 애플리케이션 로직이 들어있다.

- 뷰와 컨드롤러에서 모델의 상태를 조작하거나 가져올 때 필요한 인터페이스를 제공한다.

- 모델이 자신의 상태 변화를 옵저버들에게 연락해 주긴 하지만 기본적으로 모델은 뷰와 컨트롤러에게 별 관심이 없다.

 

 

 

---

 

 

1. 사용자는 뷰에만 접촉할 수 있습니다.

2. 컨트롤러가 모델에게 상태를 변경하라고 요청합니다.

3. 컨트롤러가 뷰를 변경해 달라고 요청할 수도 있습니다.

4. 상태가 변경되면 모델이 뷰에게 그 사실을 알립니다.

5. 뷰가 모델에게 상태를 요청합니다. 

 

[ MVC에 사용되는 패턴 ]

1. Model

- 모델은 옵저버 패턴을 사용하여 상태가 바뀔 때마 뷰와 컨트롤러에게 연락한다.

 

2. .View

- 뷰와 컨트롤러는 전략패턴을 사용한다.

- 뷰는 내부적으로 컴포지트 패턴을 써서 윈도우, 버튼 같은 다양한 구성요소를 관리한다. 

3. Controller

- 뷰의 행동에 해당하며, 다른 행동이 필요하면 그냥 다른 컨트롤러로 바뀌면 된다. 

 

 

 

---

 

 

[ 전략 패턴] 

- 뷰와 컨트롤러가 전략패턴으로 구현되어 있다.

- 뷰 객체를 여러 전략을 써서 설정할 수 있다.

- 컨트롤러가 전략을 제공한다.

- 뷰는 어플리케이션의 겉모습에 신경을 쓴고, 인터페이스의 행동을 결정하는 일은 모두 컨트롤러가 한다.

- 전략패턴을 사용하면 뷰-모델을 분리하는 데에 도움 된다.

 

[ 옵저버 패턴 ]

- 모델은 옵저버 패턴을 써서 상태가 변경되었을 때 그 모델과 연관된 객체들에게 연락한다.

- 옵저버 패턴을 사용하면 모델을 뷰와 컨트롤러부터 완전히 독립시킬 수 있다.

 

[ 컴포지트 패턴 ]

- 컨트롤러가 뷰에게 화면을 갱신해달라고 요청하면 최상위 뷰 구성 요소에게만 화면을 갱신하라고 얘기하면 된다.

- 나머지는 컴포지트 패턴이 알아서 처리한다.

 

 

 

---

[ MVC로 BPM 제어도구 만들기 ]

 

 

 

 

발췌

MVC를 배울 때 일단 여러 패턴을 합쳐 놓았다는 사실을 가장 먼저 이해하면 된다.