중재자 패턴 단점 - jungjaeja paeteon danjeom

중재자 패턴

여러 객체들이 소통하는 방법을 캡슐화하는 패턴

--> 여러 컴포넌트간의 결합도를 중재자를 통해 낮출 수 있다.

ex) 비행기들은 관제탑이라는 Mediator를 통해 서로 소통한다.

코드로 알아보기

호텔과 호텔의 여러 서비스들에 대한 코드가 있다고 해보자.

main에서 손님(guest)이 타월을 달라고 요청하고, 식사를 하려한다.

그리고 식당(resturant)이 청소를 요청한다.

현재 guest는 resturant과 cleaningService를 aggregate.

gym은 cleaningService를 aggregate

resturant은 cleaningService를 aggregate

❗️문제점❗️

각 클래스들을 보면 서로 의존관계를 얽히고 섥히게 가지고 있는 것을 볼 수 있다. 만약 BreakFast 클래스를 새로 만든다면 Restarant클래스를 extends 또는 aggregate할 것이다. 하지만 그렇게 되면 BreakFast 클래스는 CleaningService역시 aggregate하게 된다.

특히 Guest가 다양한 서비스에 대해서 구체적으로 알아야 한다.

이렇게 다양한 클래스들이 엮이게 되는 상황에서 중재자 패턴을 적용해보자.

먼저 Guest 클래스를 보자. (CollegueA)

Guest는 FrontDesk를 가지고 있는데, Cleaning서비스, Resturant서비스 등 모든 서비스를 중재자인 FrontDesk를 통해 하는 것이다.

중재자인 FrontDesk (Mediator)

FrontDesk는 중재자로써 모든 서비스들을 알고 있어도 된다. Guest가 요청한 서비스를 각 서비스들에게 전달한다.

CleaningService (CollegueB)

Restaurant (CollegueC)

그리고 위의 Resturant 역시 clean서비스가 필요하다면 직접 CleaningService에게 요청하는 것이 아니라 FrontDesk를 통해 요청하고 있다.

장점과 단점

장점

1. 컴포넌트 코드를 변경하지 않고 새로운 중재자를 만들어 사용할 수 있다.

2. 각각의 컴포넌트 코드를 보다 간결하게 유지할 수 있다.

단점

중재자 역할을 하는 클래스의 복잡도와 결합도가 증가한다. 의존성이 한 곳으로 몰린다.

실제로 어디에서 사용되나?

1. 자바의 ExcutorService,  Executor

2. 스프링MVC의 DispatcherService 

스프링MVC의 디스패처 서블릿은 다양한 핸들러, 어댑터들을 가지고 이들을 이어준다.

출처: 인프런 백기선님 '코딩으로 학습하는 GoF 강의'
https://www.inflearn.com/course/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4