[Design pattern] Mediator

Mediator pattern : 클래스간에 참조관계가 복잡해지거나 순환참조를 이루는 경우 클래스간의 결합도가 높아 코드의 재사용성과 가독성에 악영향을 끼치게된다. 여기에 중계하는 클래스(중계자)를 따로 두어 클래스간의 결합도를 M:N관계에서 M:1의 관계로 낮추는 패턴이다.

 

 (서로간에 참조가 일어나며 클래스 관계가 복잡해져있다)

 

중계자를 두어 연결되어진 클래스들은 중계자에게 통신에 필요한 인터페이스를 요구하며 이를 통해서 중계자 너머의 클래스들과 통신이 이루어지게 된다. 하지만 이런 접근은 또다른 코드의 결합성을 가져오므로 완벽한 해결이라고는 할 수 없다. 더 이상적인 해결을 위해서 Observer pattern을 적용할 수 있다. 중계자가 옵저버가 되어 참조하는 객체의 변화가 있을 때 관련된 다른 객체들에게 정해진 이벤트를 발생해주는 구조이다.

(mediator를 통해 서로를 참조되던 관계가 해결됨)

이렇게 중계자를 두는 패턴은 c++과 같은 언어에서 파일 인클루드 문제를 해결해 줄 수 있다. 그리고 클래스간의 결합도를 줄여 관리 및 유지보수 측면에서 이익을 볼 수 있다. 또한 객체간 연관되는 내용이 중계자 안에 숨겨짐으로서 구현상의 변화에 보다 쉽게 대처할 수 있다.

 

Mediator는 복잡한 관계를 인터페이스화 하고 이를 이용한다는 점에서 Facade pattern과 유사한 점이 있다. 하지만 Facade가 단방향성을 띄는 패턴인데 반해 Mediator는 양방향성을 띄는 패턴이라는 부분에 차이가있다.

 

이 패턴은 GUI의 컨트롤 간의 이벤트 트리거, 다중 클라이언트 구조 등에서 서로간의 이벤트 발생에 따른 영향을 처리할 때 활용할 수 있을것이다. 하지만 연관되는 클래스가 많아질수록 중계에 따른 비용이 증가하므로 패턴을 적용할 상황을 확실히 파악하는것이 중요하다.

 

설계가 완벽하지 않은 상태로 클래스 규모가 커지게되면, 클래스간의 참조가 빈번해지는 상황으로 흘러가기 마련이다. 초기 설계가 완벽하다 해도 변경에 따른 요구를 만족시키다보면 결국 이러한 상황에 처하게되는 경우가 많다.(정말 많다 ㅡㅡ).

이러한 상황을 미리 예측하여 필요하다고 판단되는 부분에 Mediator pattern으로 설계한다면, 규모가 커지더라도 구현의 변경에 대처하기가 한결 수월하다. Observer pattern을 적용한다면 동적인 확장에도 유연하게 대처할 수 있으므로 꽤 이상적인 모델이라 할 수 있다.

 

한줄요약 : 실행에 비용이 증가하지만, 디버깅과 유지보수에의 비용은 열배로 감소하게 될 것이다.