[GoF 디자인패턴] 중재자 (Mediator) 패턴

[leeyuunsung]

중재자 패턴 1부 - 패턴 소개

• 여러 객체들이 소통하는 방법을 추상화 시켜 결합도를 낮추는 방법
• 객체간 직접 소통하는 구조로 개발하여 결합도가 높은 경우(Tight coupled) 아래와 같은 문제점이 발생
  • 구현이 어려움
  • 코드 변경이 어려움
  • 테스트가 어려움
  • 코드 재사용이 어려움

실생활에서 중재자의 예시

• 아파트에서 층간 소음으로 문제가 있는 경우 관리사무소(중재자)에 연락하여 문제를 해결
• 비행기는 비행간 발생 가능한 이슈를 해결하기 위해 다른 비행기와 직접 의사소통하지 않고 관제탑(중재자) 를 통하게 됨

중재자(Mediator) 패턴 아키텍처

• 위 UML Diagram 에서 주목해야할 부분은 Colleague 구현체 간(Colleague A <-> Colleague B) 연결되어 있지 않다는 점 이다
• Colleague 가 Mediator 를 참조하고 있고, ConcreteMediator 가 각 Colleague 구현체를 참조하고 있음

예제(Before)

Hotel

public class Hotel {

    public static void main(String[] args) {
        Guest guest = new Guest();
        guest.getTower(3);
        guest.dinner();

        Restaurant restaurant = new Restaurant();
        restaurant.clean();
    }
}

CleaningService

public class CleaningService {
    public void clean(Gym gym) {
        System.out.println("clean " + gym);
    }

    public void getTower(Guest guest, int numberOfTower) {
        System.out.println(numberOfTower + " towers to " + guest);
    }

    public void clean(Restaurant restaurant) {
        System.out.println("clean " + restaurant);
    }
}

• 호텔을 운영할 때 다른 모든 컴포넌트(Gym, Restaurant, Guest, ...) 들은 모두 CleaningService 를 사용하도록 구현되어 있음(Tight Coupled)
• Colleague 가 다른 Colleague 를 참조하고 있는 식

[leeyuunsung]

중재자 패턴 2부 - 패턴 적용하기

예제(After)

FrontDesk

public class FrontDesk {

    private CleaningService cleaningService = new CleaningService();

    private Restaurant restaurant = new Restaurant();

    public void getTowers(Guest guest, int numberOfTowers) {
        cleaningService.getTowers(guest.getId(), numberOfTowers);
    }

    public String getRoomNumberFor(Integer guestId) {
        return "1111";
    }

    public void dinner(Guest guest, LocalDateTime dateTime) {
        restaurant.dinner(guest.getId(), dateTime);
    }
}

• 모든 의존성을 Mediator 인 FrontDesk 에 모아두고 객체간 의사소통을 중재자를 통해 하는 식
• 모든 객체들이 FrontDesk 라는 중재자만 참조하여 객체간 의사소통을 주고 받아 객체간 복잡한 의존성들이 없어지게 된다
• 이 때, 중재자는 객체 전체를 파라미터로 받지만, FrontDesk 가 필요한 요청을 다른 객체에게 요청할 때 파라미터로 객체 전체를 보내는게 아니라 필요한 최소한의 정보만 전달하여 요청한다

CleaningService

public class CleaningService {

    private FrontDesk frontDesk = new FrontDesk();

    public void getTowers(Integer guestId, int numberOfTowers) {
        String roomNumber = this.frontDesk.getRoomNumberFor(guestId);
        System.out.println("provide " + numberOfTowers + " to " + roomNumber);
    }
}

Guest

public class Guest {

    private Integer id;

    private FrontDesk frontDesk = new FrontDesk();

    public void getTowers(int numberOfTowers) {
        this.frontDesk.getTowers(this, numberOfTowers);
    }

    private void dinner(LocalDateTime dateTime) {
        this.frontDesk.dinner(this, dateTime);
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }
}

[leeyuunsung]

중재자 패턴 3부 - 장점과 단점

장점

• 컴포넌트 코드를 변경하지 않고 새로운 중재자를 만들어 사용할 수 있다
• 각각의 컴포넌트 코드를 보다 간결하게 유지할 수 있다(Colleague 들은 ConcreteMediator 만 참조하여 사용하면 되기 때문)

위 예시에서는

• FrontDesk 는 인터페이스가 아니라 클래스이기 때문에 코드의 변경이 있을 수 있음
• 이를 인터페이스로 만들어 사용할 경우, 중재자의 변경 없이 새로운 중재자로 변경하며 사용할 수 있다
• 그래서 Mediator 인터페이스를 두고 DefaultMediator(ConcreteMediator) 로 FrontDesk 를 사용하는 방식이 위의 장점에 해당된다

단점

• 중재자 역할을 하는 클래스의 복잡도와 결합도가 증가한다

[leeyuunsung]

중재자 패턴 4부 - 자바와 스프링에서 찾아보는 패턴

자바

• ExecutorService
• Executor

스프링

• DispatcherServlet
  • multipartResolver, handlerMappings 등의 컴포넌트들은 서로를 참조하여 사용하지 않음
  • DispatcherServlet 이 Mediator 로 동작하여 모든 컴포넌트들을 참조하여 동작을 수행하게 된다