[Design Patterns] Mediator

 

 

목차

개요

내용

요약

객체 집합이 소통하는 방식을 캡슐화하는 객체를 정의하자.

예시

 객체 지향에서는 코드를 나눠 한가지 일을 하는 코드 묶음으로 클래스를 구성하도록 합니다. 때로는 이런 방식이 객체들 사이에 많은 연결이 있는 구조를 만들기도 합니다. 최악의 상황으로, 모든 객체들이 거의 모든 다른 객체들을 알게끔 할 수 있습니다. 비록 시스템을 많은 클래스로 나누는 것은 재사용성을 증가시키지만, 객체간에 연결이 너무 많아지면 오히려 다시 재사용성을 떨어뜨립니다.

 다음 예제를 생각해봅시다. 우리는 GUI 프레임워크를 만드는 중에 다이럴로그를 구현해야 합니다. 다이럴로그 박스는 버튼, 메뉴, 인풋 등의 컴포넌트들을 보여주기 위해 하나의 창을 사용합니다. 보통 이럴 때 다이얼로그 안에 있는 컴포넌트들은 서로 상호작용을 합니다. 보통 다른 다이얼로그들은 다른 컴포넌트들간의 연관관계를 가집니다. 비슷하게 생긴 다이얼로그들이라도 상호작용은 다를 가능성이 높죠. 이럴 때 다이얼로그를 재사용하는 것은 어렵습니다.
 이런 문제를 해결하기 위해 중재자 객체를 만들 수 있습니다. 중재자 객체는 객체들간의 상호작용을 제어하고 조정하는 역할을 합니다. 이렇게 함으로써 객체들은 서로를 직접적으로 알지 않습니다.(Loose coupling) 아래 시퀀스 다이어그램을 봅시다

 

사용자가 다이얼로그를 열면 중재자가 다이얼로그에 있는 리스트박스와 엔트리필드를 관리합니다. 사용자가 리스트박스에 있는 아이템을 선택하면 widgetChanged라는 이벤트를 중재자에게 전달하고 중재자는 리스트박스에서 선택된 아이템을 가져와서 이에 맞게 엔트리필드에 문자를 세팅합니다. 이 과정에서 리스트박스와 엔트리필드는 서로를 알 필요가 없습니다.

구조

 

이야깃거리

언제 써야 할까?

• 객체들이 복잡하게 연결되어 있을 때
• 한 객체가 다른 많은 객체들과 연결되어 있어서 재사용이 힘들 때

장단점

• (Pros) Collegues 사이에 연결성을 낮춥니다. Loose Coupling
• (Cons) Mediator 객체가 다른 많은 객체들과 연결되어지면서 복잡하게 설계될 여지가 있습니다.

Case Study

출처

GoF Design Patterns