Software Architecture/Design Pattern

[Design Pattern] Mediator Pattern

Linuxias 2019. 1. 7. 20:13
반응형

Mediator Pattern의 목적은 명확합니다. 중간 관리자를 하나두어 문제를 해결하겠다는 것입니다.

서로 커뮤니케이션하고자하는 객체들이 있을 때 상호작용하려는 객체들의 집합의 구조가 복잡할 때 복잡성을 해소하면서 커뮤니케이션이 가능하도록 하는 목적의 패턴입니다. 매우 복잡한 커뮤니케이션 관계가 존재할 때 중앙집중적인 관리가 필요할 때 사용된다고 보시면 됩니다.


이러한 Mediator Pattern의 공항 관제탑을 생각하시면 좀 더 이해가 쉬울 것 같습니다. 인천공항에 이,착률 하려는 모든 항공사의 항공기간 서로 커뮤니케이션을 직접적으로 하는것이 아니라 중앙에 위치한 관제탑에서 정보를 수집하고 데이터를 전달함으로써 이,착륙 시 발생할 수 있는 많은 문제를 해결하고 있습니다. 


위 예시와 같이 Mediator Pattern 구조에서는 커뮤니케이션에 참여한 모든 객체간 직접적인 커뮤니케이션을 절대 발생하지 않는다는 것입니다. 만약 상호 커뮤니케이션이 직접 발생하게 된다면, Mediator Pattern의 장점이 사라지게 됩니다. 중간에 위치한 Mediator는 인터커넥션을 캡슐화하여 스스로 커뮤니케이션 허브역할을 합니다. 매우 복잡한 커뮤니케이션 플로우도 캡슐화 되어 외부로 오픈되지 않기때문에 커뮤니케이션 플로우를 이해하기 매우 쉽습니다. Mediator를 통해서 커뮤니케이션이 되는 것이기 때문입니다. 모든 커뮤니케이션 로직이 Mediator 내에 캡슐화 되기에 통신을 참여한 여러 객체간의 결합도를 매우 낮추게 됩니다. 이런 특징 때문에 GUI Component에서 많이 사용됩니다. 


단점으로는 Mediator Pattern의 경우 Mediator 자체의 재사용성이 매우 낮습니다. 복잡한 커뮤니케이션 로직을 Mediator가 떠안는 형태이기 때문에 특정 프로젝트에 사용한 Mediator를 다른 프로젝트에 재사용할 수 있는 확률은 매우 낮습니다.


이 전에 살펴본 Observer Pattern 기억나시나요? Observer pattern도 Object들 간의 커뮤니케이션을 위한 구조였습니다. 두 패턴의 차이는 명확합니다.


Observer Pattern

Observer와 Subject 객체들로 커뮤니케이션이 분산되어 있으며 재사용성이 매우 높습니다. 하지만 커뮤니케이션 플로우를 이해하기 어렵다는 단점이 있습니다.


Mediator Pattern

Mediator는 커뮤니케이션이 캡슐화되어 있습니다. Mediator가 모두 떠안는 구조이기에 재사용하기 어려우나 커뮤니케이션 플로우를 이해하기 매우 쉽습니다.

반응형