[2기 강남 안병현] GoF 디자인패턴 - Mediator 패턴

안녕하세요 강남 멤버쉽 21기 안병현입니다.

 저는 오늘 GoF디자인패턴중에서 Mediator패턴에 대해서 소개해드리려고 합니다. 디자인패턴이란 한마디로 정의내리기 어렵지만, 프로그래밍 과정에서 자주 겪는 문제점을 해결하기 위해 만들어진 정형화된 문제해결법이라고 보시면 될 것 같습니다. 수많은 디자인패턴 중에서 GoF디자인 패턴이 가장 대중적으로 알려져 있는데요. GoF 디자인 패턴은 Gang of Four라고 불리는 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 이 네명의 소프트웨어 공학 연구자들이 쓴 책 ‘Design Patterns : Elements of Reusable Object-Oriented Software’ 에서 소개된 패턴들입니다. 디자인 패턴이라는 용어도 이 책에서 처음 제시되었다고 하네요. 디자인패턴이라는 것이 GoF 디자인 패턴만 있는 것은 아니지만 가장 대중적이고 기본적인 패턴이기 때문에 익혀두면 좋습니다.

Mediator 패턴

 Mediator 패턴은 객체들의 상호작용을 캡슐화하는 패턴입니다. Mediator는 다른 객체들을 명시적으로 참조함으로써 느슨한 결합을 만듭니다. 그리고 다른 객체들의 상호작용을 독립적으로 동작하도록 만들 수 있습니다.

 잘 설계된 객체 지향 아키텍쳐라면 객체 간의 역할이 명확하고 독립적이어야 합니다. 이러한 역할 분배는 객체 사이의 많은 연결 구조를 발생시킬 수 있습니다. 최악의 경우 모든 객체가 서로를 참조하고 호출하는 복잡한 구조가 될 수 있습니다.

 많은 객체로 분할하여 설계를 하는 것은 일반적으로 재사용성을 향상시킵니다. 그러나 객체들 사이의 관계가 복잡해지면 오히려 재사용성이 떨어지기도 합니다. 예를 들어, 간단한 영화 예매 프로그램을 만들어 봅시다. 이 프로그램은 영화관을 선택하는 부분, 영화를 선택하는 부분, 영화 시간을 선택하는 부분으로 나누어집니다. 이 프로그램의 세가지 컴포넌트들 사이에는 종속성이 있습니다. 예를 들어, 영화를 선택하면 해당 영화를 상영하지 않는 영화관은 비활성화 되고, 영화 예매가 가능한 시간을 보여주어야 합니다. 반대로 영화관을 선택할 경우에는 해당 영화관에서 상영하지 않는 영화를 비활성화해 주어야 합니다. 이러한 프로그램에 새로운 컴포넌트를 추가한다면 그 컴포넌트는 다른 컴포넌트들과 또 다른 방식으로 의존성을 갖게 될 것입니다. 따라서 이러한 구조의 컴포넌트들은 재사용하기 어렵다고 볼 수 있습니다.

 Mediator 패턴을 사용하여 이러한 문제점을 해결할 수 있습니다. Mediator 객체는 다른 객체들간의 상호 작용을 제어하고 조정하는 역할을 수행합니다. Mediator 객체가 다른 객체들을 참조하여 서로 연결해주는 중개자 역할을 합니다. 따라서 다른 객체들은 Mediator 객체만을 바라보고 원하는 것을 요청하며 이러한 구조를 통해 느슨한 결합을 만듭니다.

 이와 같이 Mediator 패턴을 사용하여, SelectMovie, SelectPlace, SelectTime, 객체가 서로를 참조할 필요 없이 Mediator만을 참조하여 서로에게 영향을 줄 수 있습니다. 예를 들어 영화 선택 객체를 통해서 보고 싶은 영화를 선택합니다. SelectMovie 객체를 통해 원하는 영화를 선택하면 SelectMovie 객체는 Mediator 객체에 선택한 영화에 대하여 전달합니다. 그러면 Mediator 객체에서 SelectPlace 객체와 SelectTime 객체에 정보를 넘겨주어 상태를 변화시킵니다. 이와 같이 Mediator 객체는 다른 객체들간의 통신허브 역할을 수행한다고 볼 수 있습니다.

 객체들이 잘 정의되어 있지만 복잡한 방식으로 통신할 때,

 그 결과 상호 의존이 복잡하여 이해하기 어렵고 쳬게적이지 않을 때,

 다른 많은 객체들과 통신하고 참조하고 있어서 강한 결합을 유지할 때,

 여러 객체들이 모두 서브클래스를 사용하지 않고 구현되어야 할 때,

 이런 경우에  Mediator 패턴을 사용하면 좋습니다.

 전형적인 아키텍쳐는 위와 같습니다. Colleague 객체는 Mediator에 자기 자신과 원하는 명령을 send (String,Colleague)를 호출하여 전달합니다. Mediator 객체는 전달받은 명령과 객체를 확인하여 알맞은 명령을 수행합니다. 

 실제 구현을 할 때에는 Mediator는 하나만 사용하기 때문에 추상 클래스를 정의할 필요가 없습니다. 그리고 Colleague 객체와 Mediator 객체가 통신하는 방식으로 Observer 패턴을 사용하거나, (Observer 패턴이 궁금하신 분은 따로 찾아보시기 바랍니다. ^^) 위에 정의된 send 함수처럼 Colleague 객체가 자신을 인자로 넘겨서 통신하는 방식이 있습니다.

 Mediator 패턴에는 다음과 같은 장단점이 있습니다.

 - Colleague 객체를 사이의 상호 동작 기능을 변경하려면 Mediator만 변경하고 기존의 Colleague 객체들은 재사용할 수 있습니다.

 - Mediator 패턴은 Colleague 객체들 사이의 느슨한 연결을 가능하게 합니다. 따라서 독립적으로 Colleague 객체와 Mediator 객체를 모두 재사용할 수 있습니다.

 - Mediator 패턴은 Colleague 객체들 사이의 N:N 상호작용을 1:N 상호작용으로 변경해줍니다. 일반적으로 N:N 상호작용에 비해 1:N 상호작용이 이해하기 쉬우며, 유지 관리하기 편리합니다.

 - 제어를 중앙 집중적으로 할 수 있습니다. Mediator 패턴은 상호작용의 복잡성을 줄이는 대신 Mediator 객체의 복잡성을 늘립니다. 이것은 Mediator 객체를 너무나 거대한 객체로 만들 수도 있습니다.

 Mediator 패턴과 비슷한 Facade 패턴

 Facade 패턴은 복잡한 시스템과 통신하기 위하여 중간에 하나의 Layer 를 두고 기능을 추상화 하는 패턴입니다. 객체들간의 통신을 중계해주는 역할을 수행한다는 점에서 Mediator 패턴과 Facade 패턴은 비슷한 점이 있습니다. 그러나 Facade 패턴은 구성된 시스템으로의 단방향 요청만 처리한다는 점에서 Mediator 패턴과 다르다고 할 수 있습니다.

 지금까지 Mediator 패턴을 살펴봤습니다. 모든 디자인 패턴의 기본은 객체를 인터페이스를 통해 잘 추상화하여 재사용성을 높이는 것에 있다고 볼 수 있습니다. 앞으로 계속해서 다양한 디자인 패턴을 소개해 드리도록 하겠습니다. 즐코딩하세요 ^^