posa1 2008 view handler - andstudy/forge GitHub Wiki

View Handler 디자인 패턴

1. MVC 계열 패턴 변형의 한 종류

예제

1. 다중 문서 편집기 - 307p 그림
2. 뷰가 여러개

문제

1. 뷰들은 누가 관리하나?
2. 멋져보이는 영향력(force)
3. 사용자의 관점에서 ~ 쉽게 관리, 시스템 내의 ~ 쉽게 관리.
4. 개별 뷰들이 서로 종속되어서는 안 되며 어쩌고 저쩌고...
5. 변경가능, 추가가능.
6. 한마디로 멋지고 유연하게...
7. 다중 뷰를 관리하는 책임은 누가 가져야 할까요?
8. 예 - 뷰들을 격자 정렬(tile) 하는 책임은 어느곳에?

해법

1. 뷰 핸들러 (View Handler) - 짜잔~
2. 특정 뷰의 조정, 핸들링
3. MVC의 입자가 고운 패턴

win32 MDI

1. {{{MainFrame, ChildFrame, View, Document}}}
2. 프레임 개념의 도입
3. 뷰 핸들러는 메인프레임이라 볼 수 있다.

여기서 잠깐! POSA 에 대한 실망

1. 뜬구름 잡기 vs 이제 식상
2. Black Board (안드로메다?)
3. Reflection - 언어에서 지원, Whole Part - 객체지향이면 당연
4. View Handler - 프레임워크에서 지원
5. 구현 할 수 없거나 이미 되어있거나

구조

1. 다이어그램 311p
2. 한마디로 뷰핸들러는 여러개의 뷰를 가진다. 끗?
3. View Handler
4. 소프트웨유 시스템의 뷰들을 열고 조작하고 닫는다.
5. Abstract View
6. 모든 뷰에 공통적인 인터페이스 정의
7. Specific View
8. 자체 디스플레이 함수 구현
9. Supplier
10. 데이터 제공 (document?)

동작

시나리오 1 - 뷰 생성

1. 뷰핸들러가 뷰를 만들고, 만든 뷰들을 가진다.
2. 뷰는 서플라이어에서 데이터를 가져온다.
3. 뷰는 서플라이어에 등록한다 (옵저버네요?)
4. 뭐 별거 없네요?

시나리오 2 - 뷰 격자 정렬

1. 뷰핸들러에서 각 뷰를 돌면서 resize, move 호출
2. 역시 별거 없네요?

구현

1. 옵저버, 팩토리, 이터레이터, 미디에이터를 버무려보자.
2. 뷰는 추상뷰와 상세뷰로 상속 구조

구현 순서

1. 필요한 뷰를 정의한다
2. 모든 뷰들에 대한 공통 인터페이스를 정의한다.
3. 뷰를 구현한다.
4. 뷰 핸들러를 정의한다.
5. openView() - new 해서 add 한다. 끗

변형

1. 커맨드 객체
2. 뷰 핸들러는 뷰의 함수를 직접 호출하지 않고 커맨드 객체를 넘긴다

용례

1. 맥킨토시 창 관리자 - 314p 인터페이스보다 좀 많다
2. 마이크로소프트 워드 - 요즘은 좀 달라지지 않았나요? MDI인것도 아니고 아닌것도 아니여.

결과

장점

1. 단일한 방식으로 뷰를 처리한다.
2. 뷰에 확장성과 가변성을 지원한다.
3. 특정 애플리케이션에 적합하도록 뷰를 조정 할 수 있다.
4. 한마디로 폼나고 유연하다. - 폼(form)이 국어사전에 있다니

단점

1. 적용성에 다소 제약이 있다.
2. 효율성이 떨어지는 경향이 있다.
3. 단점은 뭐 사소해 보인다

나의 결론

1. A 핸들러를 만들어 많은 A 들을 관리해라. (님아~ 너무 뻔한거 아닌가요? ㅜ.ㅜ)