Pattern Tips 의 5

Pattern Tips 의 5 저자: 온 욱
감사: 라 는 책의 저자 Gamma, Helm, Johnson 과 Vilsides, 번역자 이 영 군 등
설명
Builder，Visitor，Observer，Mediator。그것들 은 모두 Behavioral Patterns 이다.
더 중요 한 것 은 그들 은 모두 비교적 '어 려 운' 모델 이다. 그들의 공통점 은 모델 자체 에 여러 개의 Role 합작 이 있다 는 것 이다. 예 를 들 어 Builder / Director, Visitor / Element, Observer / Subject, Mediator / Colleague 등 이다.
----------------------------------Builder----------------------------
● Tip 1: 키워드.Complex，Assemble。
● Tip 2: 그림.
Director 는 '거시적인 과정' 만 제어 하고 구체 적 인 업무 의뢰 (delegate) Builder 가 하 는 것 을 볼 수 있다.
● Tip 3: 실현 과 사용.
'Architect 또는 Achitecture 엔지니어' 는 Director 와 Builder 를 쓴다.한편, Product 과 Part 의 실례 화 (그리고 Part 를 조립 한 Product) 는 Builder 의 가장 중요 한 직책 이다.
"Application 엔지니어" 는 Client, Director, Builder 를 작성 하 는 것 을 책임 집 니 다. 일반적으로 이 Client 에서 예화 합 니 다.Director 는 어떤 Builder 를 구체 적 으로 호출 할 것 인지 클 라 이언 트 가 Director 에 게 알려 줍 니 다.
MFC 에 서 는 App / CCtrlView / List View / List Ctrl / Column and Item 이 각각 Director / Abstract Builer / Concrete Builer / produt / part 이다.
● Tip 4: 장점.Finer control over the assembling process。
제어 하 는 '입도' 는 Director 와 Builder 의 분리 에 비교적 정교 하 게 나타난다. (Abstract Factory 는 'construct products in one shot' 인 것 을 생각해 보 자) Builder 의 직책 은 Create a part and assemble it to product 이 고 Director 의 직책 은 Control builder 's assembling process 이다.
Director 의 서로 다른 쓰기 방법 을 통 해 서로 다른 수 요 를 만족 시 킬 수 있 습 니 다. 예 를 들 어 전략 게임 의 Director 는 지도 파일 을 읽 고 지 도 를 만 들 수 있 습 니 다. 문서 형식 변환 프로그램의 Director 는 '소스 형식 파일' 을 읽 고 '목표 형식 문서' 를 만 들 수 있 습 니 다.'사용자 구동' 일 수 있 습 니 다. 예 를 들 어 Word 나 Photoshop 등 편집 소프트웨어 의 Director 는 큰 메시지 순환 으로 사용자 의 조작 에 따라 문 서 를 구체 적 으로 구성 할 수 있 습 니 다.물론 assembling process 하 드 인 코딩 도 가능 합 니 다. 예 를 들 어 책 에 첨부 된 예 와 같 습 니 다.

Maze* MazeGame::CreateMaze( Mazebuilder & builder )
{
  builder.BuildMaze();  //create the Product

  builder.BuildRoom(1);  //create 3 Parts of Product and assemble them to the Product
  builder.BuildRoom(2);
  builder.BuildDoor(1, 2);

  return builder.GetMaze();
}

● Tip 5: 변 화 를 지원 합 니 다.
Director 는 Builder 를 호출 하여 '입자 도' 의 통 제 를 달성 할 수 있 으 며, AbstractBuilder 라 는 매우 안정 적 인 인터페이스 로 협력 을 구축 할 수 있 으 며, Director 와 ConcreteBuilder 사이 에는 직접적인 결합 관계 가 존재 하지 않 습 니 다.그래서 Director 와 Concrete Builder 는 상당히 자 유 롭 습 니 다.그림 에서 노란색 Director 는 새로운 Assemble 전략 을 지원 하기 위해 새로 쓴 것 으로 'Architect 또는 Achitecture 엔지니어' 를 기 쁘 게 하 는 것 은 Builder 와 그 하위 클래스 에 대해 어떠한 변경 도 하지 않 았 다 는 것 이다.
----------------------------------Visitor----------------------------
● Tip 1: 키워드.New Operation。
● Tip 2: 그림.
이 를 통 해 알 수 있 듯 이 'Aalgorithm 을 Data 에서 분리' 하 는 목적 을 달성 하기 위해 대 가 는 1.5 개 대상 이다. 방문 자 를 추가 하고 Element 는 Accept () 작업 을 추가 하 는 것 이다.
● Tip 3: 실현 과 사용.
CWnd:: SubclassWindow () 또는 CWnd:: SubclassDlgItem () 일 때 CWnd 는 window obj 의 Visitor 라 고 생각 합 니 다.
● Tip 4: 장점.알고리즘 이 집중 되 어 유지 하기 쉽다.Related behavior isn''t spread over the classes defining the object structure; it''s localized in a visitor。
● Tip 5: 변 화 를 지원 한다.Visitor makes adding new operations easy。그림 속 노란색 클 라 스 는 가상 으로 확 대 된 것 이다.
● Tip 6: 한계.
The classes defining the object structure rarely change 에 만 사용 할 수 있 지만, you often want to define new operations over the structure.Most of these operations will need to treat nodes that represent assignment statements differently from nodes that represent variables or arithmetic expressions.그래서 Adding new ConcreteElement classes is hard.그래서 If the object structure classes change often, then it 's probably better to define the operations in those classes.
Visitor and Element 사 이 는 긴밀 한 결합 입 니 다.Breaking encapsulation. Visitor''s approach assumes that the ConcreteElement interface is powerful enough to let visitors do their job. As a result, the pattern often forces you to provide public operations that access an element''s internal state, which may compromise its encapsulation.
----------------------------------Ovserver----------------------------
● Tip 1: 키워드.Notify，Dependency。
● Tip 2: 그림.먼저, concreteListener 가 concreteBroadcaster. AddListener (this) 의 '구독' 메 시 지 를 호출 하 는 것 을 볼 수 있 습 니 다.그리고 어느 날, concrete Broadcaster 는 Broadcast () 를 호출 하여 메 시 지 를 구독 한 concrete Listener 의 ListenToMessage () 를 호출 하여 실 행 됩 니 다.
● Tip 3: 실현 과 사용.
When the dependency relationship between Broadcasters and Listeners is particularly complex, an object that maintains these relationships might be required. We call such an object a ChangeManager. ChangeManager is an instance of the Mediator pattern.
MFC 에서 CView 는 CDocument 의 Observer, CListView 는 CListCtrl 의 Observer 다.
설명 할 필요 가 있 는 것 은 전형 적 인 Mediator 모델 에서 각 Colleague 는 완전히 '평등' 하고 그 어떠한 Colleague 의 변화 도 다른 Colleague 에 해당 하 는 변 화 를 일 으 킬 수 있다 는 것 이다.그러나 이곳 의 Colleague 는 Broadcaster 와 Listener 가 맡 고 있 습 니 다. 그들 은 '불평 등' 입 니 다. Broadcaster 는 항상 발기인 이 고 Listener 는 항상 응답 합 니 다.하하, 이 관점 에서 Facade 도 일종 의 Mediator 입 니 다.
다음 그림 에서 Change Manager 는 broadcaster 가 있 습 니 다.listener_map 데이터 구 조 는 매우 복잡 할 수 있 습 니 다. Broadcaster: AddListener () 와 Change Manager: Register () 의 매개 변 수 는 모두 상응 하 게 복잡 해 야 합 니 다. 예 를 들 어 '특정한 Broadcaster 의 정 보 를 구독 하 는 것' 에서 '특정한 Broadcaster 의 특정한 정 보 를 구독 하 는 것' 또는 '모든 유형의 이 자 를 구독 하 는 것' 으로 바 뀌 어야 합 니 다.
Observer pattern appears in Smalltalk Model/View/Controller (MVC)。。。 ● Tip 4: 변 화 를 지원 한다.The Observer pattern lets you vary subjects and observers independently. All a subject knows is that it has a list of observers, each conforming to the simple interface of the abstract Observer class。그림 과 프레임 워 크 의 대상 과 관련 된 의존 은 모두 양성 의존 이 고 녹색 으로 표 시 됩 니 다. 바로 이러한 양성 의존 으로 인해 애플 리 케 이 션 의 Changeable 성 이 높 은 대상 이 자 유 롭 게 변화 할 수 있 습 니 다.
● Tip 5: 프레임 워 크 지원.하나의 메시지 플랫폼 에 해당 하 며 그림 에 표시 되 어 있 습 니 다.
----------------------------------Mediator----------------------------
● Tip 1: 키워드.Collective Behavior。
● Tip 2: 그림.
여러 개의 Colleague 가 변 할 때 Mediator 에 보고 하 는 것 을 볼 수 있 습 니 다.Mediator 는 구체 적 으로 어떤 Colleague 의 obj 에 변화 가 생 겼 는 지 에 따라 관련 Colleague 의 작업 을 호출 합 니 다.
● Tip 3: 실현 과 사용.Colleague passes a reference to itself as an argument to ColleagueChanged() to let the Mediator identify the Colleague that changed。
MFC 의 Dialog 는 전형 적 인 Mediator 로 모든 control 이 메 시 지 를 보고 합 니 다.
● Tip 4: 장점.It centralizes control. That can help clarify how objects interact in a system. The Mediator pattern trades complexity of interaction for complexity in the mediator.Colleagues send and receive requests from a Mediator object. The mediator implements the cooperative behavior by routing requests between the appropriate colleague(s).
● Tip 5: 변 화 를 지원 한다.It decouples colleagues. A mediator promotes loose coupling between colleagues. You can vary and reuse Colleague and Mediator classes independently。Mediator:: ColleagueChanged () 의 구체 적 인 실현 을 바 꾸 어 서로 다른 '업데이트' 전략 을 실현 할 수 있 습 니 다.Colleague 를 추가 할 수도 있 고, Mediator 는 약간의 변경 만 하면 된다.그림 에 노란색 으로 표시 하도록 변경 하 다.