이 번호에 이야기해 보고자 하는 디자인 패턴은 “Mediator[1]”라는 이름을 가지고 있다. 사전을 찾아보면 ‘중재자’ 정도의 의미를 가지고 있는 단어이다. 이 패턴을 이 번호의 이야기 거리로 삼은 이유는 지난 호의 Observer 패턴[1]의 ‘관련 패턴’ 절에서 언급했듯이 Observer패턴과 유사한 부분이 있고 깊이 생각해 볼 문제를 다루고 있다고 생각하기 때문이다.

1.  의존성(dependency)의 발견

지난 호에 이야기했듯이 객체지향 시스템의 기본구조를 가만히 살펴보면, 그 구조는 객체들과 그 객체들 사이의 어떤 특정한 관계(association)로 되어 있으며, 그 관계를 따라서, 객체들 사이에 어떤 특정한 행위(behavior)를 유발시키는 메시지(message)가 왔다 갔다 하는 것으로 이해할 수 있다고 생각한다. 그런데, 객체지향 시스템을 디자인 할 때, 바로 이 부분에서 우리가 주의를 기울여야 하는 부분이 보인다. 객체들 사이의 메시지 전달을 통한 의존성(dependency)이 바로 그것이다. 하나 이상의 객체들이 모여서 어떤 특정한 관계를 유지함으로써, 다시 말해서, 서로간의 어떤 의존성을 가짐으로써 해당 객체지향 시스템이 본래 의도하던 행위를 가지게 된다는 점에서는 이러한 의존성이 필연적이지만, 대부분의 경우에는 이런 객체들 사이의 의존성을 최소화하는 것이 전체 시스템의 안정성을 증대 시키고 관리를 쉽게 할 수 있을 것이다. 또한 해당 시스템을 구성하는 콤포넌트 중에서 재사용성이 크다고 판단되는 것들에 대해서는 해당 콤포넌트가 다른 콤포넌트와의 관계를 통한 행위를 지역화(localization)함으로써 해당 시스템을 보다 유연하게 만들뿐만 아니라, 그 부분을 다른 시스템에서도 거의 그대로 사용할 수 있는 재사용성을 높일 수 있을 것이다.  Mediator 패턴은 바로 위에서 이야기한 두 가지 문제, 즉, 객체간의 의존성을 최소화 시키고, 행위를 지역화 시킬 수 있는 한 가지 효과적인 방안을 제시해 주고 있다. 물론 절대적인 해법은 아니다. 하지만, 이 두 가지 (중요한) 문제를 생각하게 만든다는 점에서 잘 살펴볼 만한 가치가 있는 패턴이라고 생각한다. 

너무 일반적이고 추상적으로 이야기를 했다. 구체적인 예를 들어서 다시 문제의 중요성을 생각해 보자. 

Mediator 패턴을 이야기할 때 항상 언급하는 예로 대부분의 개발자나 시스템 디자이너가 쉽게 접할 수 있는 ‘다이알로그 박스(dialog box)’가 있다.  그림 1은 익스플로러의 파일 열기 다이알로그 박스를 필자가 캡쳐(capture)한 것이다. 

그림 1의 파일 열기 다이알로그 박스를 보면서 위에서 이야기 했던 것을 다시 생각해 보자. 그림 1을 보면 ‘찾는 위치’를 표시하는 ComboBox에 나타나 있는 디렉토리에 속해 있는 디렉토리와 파일들이 ListBox에 나타나 있다. 그 중에서 ‘designpatterns1.html’이라는 파일이 반전되어 선택되어 있고, 그 선택된 파일은 다시 ListBox아래의 ‘파일 이름’으로 이름 붙여진 ComboBox에 표시되어져 있다. 여기서 눈여겨 볼 내용 중에 하나는 ListBox에 선택된 파일이 그 아래 ComboBox에 표시된다는 것이다. 거꾸로 이야기해서, ListBox에서 선택되어지지 않은 파일은 ComboBox에 표시되지 않는다. 즉, ComboBox는 ListBox에 의존성을 가진다. 다른 부분을 보자. 파일 열기 다이알로그 박스의 제일 아래에 위치한 ‘파일 형식’이라 이름 붙여진 ComboBox에는 ‘HTML 파일’이라는 내용이 표시되어 있으며, 이 내용에 따라서, ListBox에는 html 파일 형식을 가지는 파일만이 표시되고 있다. 즉, 파일 filtering을 하고 있다. 이 두 객체의 관계를 보면 앞에서와는 다르게 ListBox가 ComboBox에 의존성을 가지고 있다. 이야기를 단순화 시키기 위해서 파일 열기에 속해 있는 객체들 중에서 위에서 언급한 객체들만을 가지고 그 관계를 클래스 다이어그램으로 표시하여 보면 그림 2와 같은 의존성이 나타날 것이다(그림 2의 각 객체가 단 하나의 클래스로 되어 있다고 가정한다).
 

그림 2를 보면 각 객체의 의존성이 눈에 쉽게 들어온다. 여기서 그림 2를 보고 좀 답답함을 느껴야 할 것이다. 위에서 ListBox는 무려 세 개의 객체와 이런 저런 의존성을 가지고 있다.  그림 2의 디자인대로 그림 1의 다이알로그 박스를 구현했다고 가정해 보자.  이 경우에 ListBox를 구성하고 있는 코드에는 ListBox가 가지고 있는 고유의 기능, 즉, 파일시스템의 내용을 보여 주는 기능 외에 다른 세 개의 객체와의 의존성에 따른 코드가 들어가게 될 것이다. 구체적으로 이야기해서, ‘찾는위치ComboBox’와 ‘파일형식ComboBox’의 상태변화를 관찰하는 코드가 들어갈 것이고(Observer 패턴과 유사한 이야기?),  ‘파일이름ComboBox’를 위한 자신의 상태 변화를 알려주는 인터페이스를 위한 코드가 들어갈 것이다. 정말로 이렇게 디자인하고 구현을 했을까? 절대로 아니다. 만약 이렇게 구현을 했다면, 이 소스는 그림 1을 위한 다이알로그 박스에서만 사용할 수 있는 코드가되어 버릴 것이다. 그림 1과 같은 다이알로그 박스가 너무 특수한 경우에만 사용되어지는 객체라면 이야기가 조금 다르지만, 다른 곳에도 아주 유용하게 사용되어 질 수 있는 ListBox와 ComboBox를 위의 가정대로 강한 의존성을 주어 디자인하고 구현한다는 것은 미친짓이 될 것이다. 그 이유는 Windows 프로그래밍을 한 번이라도 관심 있게 본 개발자라면 잘 알고 있을 것이다. ‘Hello World’라는 문자를 표시하는 윈도우를 하나 그리는데 필요한 코드가 거의 50라인 정도가 필요하다는 것을.   

2.  그럼 어떻게 할 것인가?

그런 어떻게 하면 그림 2와 같은 필연적인 의존성을 최소화하여, 사용된 위젯(Widget)의 재사용성을 높일 수 있을까? 가장 쉽게 생각할 수 있는 것은 그림 1과 같은 다이알로그 박스가 해야 되는 행위를 하기 위해서 필연적인 메시지 전달을 다른 객체에 위임(delegation)하는 것이다. 좀 쉽게 이야기하면, 각 객체가 자신과 의존성을 가지고 있는 객체에 직접 메시지를 전달하는 것이 아니라, 이 일을 다른 객체에 부탁하는 것이다. 이렇게 함으로써, 각 객체는 메시지 전달을 대행하는 객체의 일관된 인터페이스만 기억하고 있으면 되고, 메시지를 전달하는 이 대행 객체를 위한 동일한 인터페이스를 제공함으로써, 다른 어떤 객체에도 의존성을 가지지 않는 객체가 될 수 있는 것이다. 이 방법을 정리한 것이 바로 Mediator 패턴이다. 좀더 구체적으로 그 이점을 보이기 위해서 그림 2의 디자인에 이 방법(Mediator 패턴)을 적용하여 보았다. 그림 3은 그림 2에 Mediator 패턴을 적용하여 다시 디자인한 것이다.
 

그림 3에 보면 ListBox와 ComboBox 들은 그림 2의 디자인처럼 서로 직접적으로 메시지를 전달하지 않고, FileDialogMediator를 통하는 간접적인 방법을 택하고 있다.  FileDialogMediator는 이 들 객체들 사이에서 메시지 전달을 대신해주는 기능을 하고 있다. 이를 위해서 FileDialogMediator는 Widget이 자신의 상태가 변했다는 것을 알려줄 수 있는 통로로 widgetChanged()라는 이름의 인터페이스를 제공하고 있고, 각 Widget은 FileDialogMediator로 Widget 고유의 메시지 교환을 위한 인터페이스를 제공하고 있다.  그림 3의 예를 보면 ComboBox는 setText() getText()라는 인터페이스를 ListBox는 setTextField()와 getTextField()라는 인터페이스를 제공하고 있다. 

그림 3과 같이 디자인함으로써, 각 Widget들 간에 존재하던 의존성이 사라지고, 그 행위가 FileDialogMediator라는 객체에 집중되는 결과를 초래했다. 즉, 앞에서 이야기한대로 시스템의 의존성은 줄이고, 행위에 대해서는 지역화를 가져오게 되었다. 이런 결과는 행위에 변화를 주어야 할 필요성이 있을 때에는 Mediator 부분만 고쳐주면 되고 다른 Widget들은 그대로 사용할 수 있게 되었다는 의미로써, 결과적으로는Widget의 재사용성을 높이게 되었다. 

3.  Mediator 패턴

그림 3의 디자인을 일반화 시켜서 GoF책의 저자들이 Mediator 패턴이란 이름을 붙여서 정리하여 놓았다. 그림 4는 GoF 책의 Mediator 패턴을 필자가 UML로 바꾸어 표현한 것이며, 그림 3의 예와 비교하면 FileDialogMediator를 Mediator로 Widget을 Colleague로 일반화 되어 표현되어 있다.
 

어떤가? 해법이 너무 단순하다고 생각하지 않는가? 하지만, 이런 단순한 해법이 위에서 고민했던 중요한 문제들을 너무도 멋드러지게 해결할 수 있다. 지금까지 봐왔던 모든 디자인 패턴이 그래왔듯이…

GoF책 저자들이 밝히고 있는 Mediator 패턴의 의도를 정리하는 것으로 이 번 글을 마무리 짓겠다.
 

의도(intent)

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Mediator 패턴은 한 무리의 객체들 간의 상호 작용에 따른 행위를 지역화(localization)시킴으로써 각 객체들이 명시적으로 참조해야 하는 필요성을 없애준다. 결과적으로 이 패턴은 각 객체간의 의존성을 줄여서 그 들간의 다양한 상호 작용이 가능하게 해 준다.

4.  관련 패턴

이 패턴의 저자들이 관련이 있다고 언급한 패턴 중에는 Observer패턴이 있다.  지난 호를 읽어 본 독자들은 Mediator 패턴의 어느 부분이 Observer 패턴과 비슷한지 이미 알아차렸을 것이다.  어느 부분이 관련이 있는가?  바로 Mediator가 Colleague의 상태 변화를 주시하는 부분이다. 그 다음 관계가 있다고 이야기한 패턴으로는 Fa?ade 패턴[1]이 있다.

5.  맺음말

GoF책에 소개되어 있는 디자인 패턴은 보면 볼수록 신기하다는 생각이 든다. 그 패턴들을 보면 하나같이 그 구조가 참 단순하다는 것을 쉽게 확인할 수 있는데, 놀라운 사실은 이 단순한 해법이 우리의 주변에 있는 복잡한(?) 소프트웨어 시스템의 일반적인 해법들이라는 것이다. 필자가 이 사실에 남다르게 놀라는 이유가 있다. 필자는 대학에서 ‘전산학’이 아닌 ‘물리학’을 전공했는데, 그 분야에서도 ‘단순성’은 아주 중요하게 취급되고 있는 개념이기 때문이다. 자연을 이해하는데 해법이 복잡하게 나오면 어딘가에서 자신이 잘못되었다고 생각해 봐야 한다는 생각은 이 분야에서 거의 절대적이다. 이런 관점에서 생각해 보면, 자연이 단순성에 기반하여 운행되고 있고, 따라서, 인간의 모든 작용도 그러할 수 밖에 없으며 결과적으로 디자인 패턴으로 정리된 여러 문제들의 해법들도 단순한 것이 당연한 결과가 아닐까? 너무 지나친 비약인가? ^(^

다음 호의 주제거리로 또 다른 흥미로운 꺼리를 찾아봐야 겠다. 
 

참고 문헌

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 
      Design Patterns, Elements of Resuable Object-Oriented 
      Software,  Addison-Wesley, 1995 

[2] Mark Grand, Patterns in Java, volume 1, Wiley, 1998