모든 글은 유튜브 얄팍한 코딩사전에 출처를 두고있습니다.
이번에 알아볼 패턴은 Mediator 패턴이다.
Mediator?
Mediator는 중재자라는 의미이다.
그 의미에 걸맞게 아래와 같이 간단히 정의할 수 있겠다.
객체 간의 상호작용을 캡슐화하여 코드를 간결하게 하자!
역시 간단한 정의만으로는 그 의미를 알기 쉽지않다.
아래로 내려가서 더 자세하게 알아보자.
사용 이유
예를 들어 나는 지금 두 가지 종류의 뷰를 제공하고 싶다.
ListView, GalleryView 두 종류의 뷰를 사용자에게 제공할 것인데,
간단하게 터치 한 번으로 뷰를 넘어가도록 하고 싶다.
터치를 할 때마다 두 뷰의 상태가 바뀌고 데이터를 새로 불러오도록 해야 한다.
패턴 없이 코드를 그대로 구현해보면 아래와 같을 것이다.
toggle() 메서드만을 사용해서 두 뷰를 왔다갔다 할 수 있는데,
코드를 이대로 두면 코드의 크기가 커졌을 때 매우 곤란해진다.
toggle() 메서드를 매번 수정을 해주어야 할 뿐더러,
점점 기능이 많아져 클래스가 많아질 수록 클래스들에 대해 모두 알아야 한다.
이는 개발자에게 매우 큰 부담이며, 유지 보수에도 부적합하다!
이럴 때 도움이 되는 것이 바로 Mediator!_
구현
아래와 같이 중재자 클래스를 구현할 수 있다.
원활한 중재자 패턴화를 위해 Listener도 생성해준다.
아래와 같이 구현된 Listner에 의해 중재자도 간결해진다.
Listner의 배열을 생성하여 다루고 싶은 클래스를 제어한다.
결국 최종적으로 사용자는 아래와 같이 메서드를 호출한다.
중재자 클래스에서 Listener 들을 추가하도록 하고,
각 Listener들에게 이벤트를 지시하는 메서드만 실행시킨다.
사용자는 결국 중재자에 대한 사용법만 알면 된다!
새 클래스가 필요할 땐 Listener를 확장 하도록 한다.
동작에 수정이 필요할 땐 Listener에서만 변경하면 된다.
즉, 우리는 변경을 최소화하여 OCP를 어느정도 확보할 수 있었다!
이 패턴을 보다 쉽게 이해하려면 회사와 외주업체를 생각하면 될 것 같다.
ModeSwitch가 회사를 담당하는 클래스라고 생각하고,
Mediator가 외주업체를 담당하는 클래스라고 생각을 해보자.
그럼 회사에서 어떤 이벤트를 발생시킬 때마다 외주업체에 연락하는 것이다.
이런이런 이벤트를 발생시켜 주세요~ 하고 Listener를 추가하는 것이다.
그럼 외주업체에서는 등록된 Listener들에게 이벤트를 지시하는 것이다.
여러 회사와 여러 외주업체가 동시에 N:N 관계를 가질 수도 있을 것이다.
그럴 떄, Mediator 패턴이라면 유연한 확장이 가능할 것이다!