Object-Oriented 디자인은 객체들 사이의 행위 분산을 장려한다. 그런 분산은 객체들 사이에 많은 연관을 지닌 객체 구조로 나타날 수 있다. 최악의 경우에는 모든 객체가 결국 모든 다른 객체들을 알게 된다.
비록 하나의 시스템에 많은 객체들이 참여하는 것이 일반적으로 재사용성을 강화할지라도 interconnections이 늘어나는 것은 재사용성을 감소시키려는 경향이 있다. 너무나 많은 객체간의 상호 연결들은 객체들의 독립성을 떨어뜨릴 수 있다. - 그런 시스템은 마치 완전히 통일된 것 같이 행동한다.
게다가 하나의 시스템에 많은 객체들이 참여하는 것은 어떤 의미있는 방법으로 시스템의 행위를 바꾸는 것을 어렵게 한다. 왜냐하면, 행위는 많은 객체들 사이로 분산되어 졌기 때문이다. 결론적으로 당신은 아마 그런 시스템의 행위를 customize하기 위해서 수많은 subclass들을 정의해야 할 것이다.
예로써 어떤 GUI상에서 다이얼로그 박스의 구현을 고려해보자. 하나의 다이얼로그 박스는 작은 도구들(버튼, 메뉴, 입력 필드)의 모음을 표현하는 하나의 윈도우를 사용한다.
대게 다이얼로그의 도구들 사이에는 어떤 dependency들이 존재한다. 예를 들면, 어떤 버튼은 어떤 입력 필드가 비어있을때는 비활성화 되어있는다. list box라 불리는 선택 목록에서 객체를 선택하는 것은 입력필드의 내용을 바꿀 것이다. 바꿔말하면, 입력필드에 문자를 타이핑하는 것은 자동적으로 리스트 박스에서 하나이상의 대응대는 입력을 선택하는 것이다. 한번 텍스트가 입력 필드에 나타나면, 다른 버튼들은 아마 활성화 될것이다. 그래서 사용자가 텍스트로 어떤 일을 하게 하게할 것이다. 예를 들자면, 관련있는 것을 삭제하거나 변경하거나 하는 따위의 일을 할 수 있을 것이다.
다른 다이얼로그 박스들은 도구들 사이에서 다른 dependency들을 지닐 것이다. 그래서 심지어 다이얼로그들이 똑같은 종류의 도구들을 지닌다 하더라도, 단순히 이전의 도구 클래스들을 재사용 할 수는 없다. dialog-specific dependency들을 반영하기 위해서 customize되어져야 한다. subclassing에 의해서 개별적으로 도구들을 Customize하는 것은 지루할 것이다. 왜냐하면 많은 클래스들이 그렇게 되어야 하기 때문이다.
별개의 mediator 객체에서 집단의 행위로 encapsulate하는 것에 의해서 이런 문제를 피할 수 있다. 하나의 mediator는 객체들 그룹 내의 상호작용들을 제어하고 조정할 책임이 있다. 그 mediator는 그룹내의 객체들이 다른 객체들과 명시적으로 조회하는 것을 막는 중간자로서의 역할을 한다. 그런 객체들은 단지 mediator만 알고 있고, 고로 interconnection의 수는 줄어 들게 된다.
다음 interaction diagram은 객체들이 리스트박스의 선택에서 변화를 다루기 위해 협동하는 방법을 묘사하고 있다.
Here's the succession of events by which a list box's selection passes to an entry field.
여기서는 list box에서의 선택이 entry field 로 전달되고 있는 이벤트들의 흐름이 있다.
- 리스트 박스가 그것의 director에게 그것이 변했다고 말한다.
- director는 리스트 박스로 부터 선택을 얻는다.
- director는 입력 필드로 선택을 넘긴다.
- 이제 입력 필드는 어떤 문자를 포함한다. director는 행동(글씨를 굵게 하거나 기울이게 하는 따위의 행동)의 초기화를 위해 버튼을 활성화 한다.
director가 리스트 박스와 입력 필드 사이의 조정하는 방법을 요약하자. 도구들은 서로 단지 간접적으로 director을 통해서 통신한다. 그들은 서로에 대해서 몰라야 하며, 그들 모두는 director를 알아야 한다. 게다가 행위는 한 클래스에 지역화 되어지기 때문에 행위는 클래스를 확장하거나 교체함으로써 변하거나 바꿔질 수 있다.