Extremely Agile:

지난 시간에 이어서 미디에이터 패턴에 대한 이야기를 좀 더 써보도록 하죠. 오늘은 구현에 대한 이야기를 좀 중점적으로 해보도록 하겠습니다.

자. 그러면 이제 지난  시간에 이야기했던 요구사항을 코드로 옮겨봅시다. 대략적인 Pseudo-code 수준의 Java 코드이니까 이 코드가 입력만 하면 우아하게 컴파일되어 돌아갈거라는 기대는 하지 않도록 합시다. ㅋㅋ

자. 우선 관리자가 들고다닐 단말기는 뭔가 공통된 인터페이스를 준수하도록 만들면 좋을 것 같습니다.

class Mediator;

interface Handheld {  
    public void setWarningMessage(String msg);
    public void registerMediator(Mediator m);
}

경고 메시지를 해당 단말기에 보내는 데 쓰일 메소드도 추가해 두었습니다. 자. 그러면 Mediator 클래스에는 Handheld 객체들을 Mediator에 등록할 메소드가 필요하겠네요.

class Mediator {
    private List<Handheld> handheld_list = new List<handheld>();

    public void registerHandheld(Handheld h) {
        handheld_list.add( h );
        h.registerMediator( this );
    }

    public void raiseWarning(String msg) {
        for ( Handheld e: handheld_list ) {
            e.setWarningMessage( msg );
        }
    }
}

여기까지는 간단하군요. raiseWarning은 Mediator에 등록된 단말들에게 Warning 메시지를 전송하기 위해 필요한 메소드입니다. 이 메소드를 호출하는 주체는 아마 Sensor가 될 겁니다. 이 메소드 덕분에, SENDOR는 어떤 종류의 Handheld 객체들이 있는지 몰라도 해당 객체들에 경고 메시지를 전송할 수 있습니다. 물론 Mediator 객체를 통해서요. 이것이 바로 Mediator 패턴의 장점입니다.

자. 그러면 Handheld 인터페이스를 구현하는 클래스 하나를 만들어 볼까요?

class PDA implements Handheld {
    private Mediator mediator = null;

    public PDA() {
        mediator = null;
    }

    public void setWarningMessage(String msg) {
        System.out.println("[WARNING] " + msg); // 다른 형태의 출력 코드로 바뀔 수 있음
    }

    public void registerMediator(Mediator m) {
        mediator = m;
    }

    public boolean shutdownCoolingPan(int panID) {
        if ( mediator == null ) {
            System.err.println("Not connected to Mediator");
            return false;
        }

        return mediator.shutdownCoolingPan( panID );
    }
}

위의 shutdownCoolingPan 메소드는 PDA 객체를 사용하는 사용자가 임의로 공장내의 냉각기 중 하나를 꺼버리고 싶을 때 사용하게 되는 메소드입니다. 그런데 이 메소드 코드 안을 보니 Mediator 클래스 안에 shutdownCoolingPan 메소드가 정의되어야 함을 알 수 있어요. 그럼 이제 Mediator 클래스를 고쳐야겠군요. shutdownCoolingPan 메소드가 에어컨들과 통신해야 할테니, 에어컨 클래스 같은 것들도 만들어야 하겠어요.

자. Mediator 패턴의 구현은 이런 식으로 진행됩니다. 구현의 나머지 부분은 비슷비슷하니까 생략하도록 하죠.

이처럼, Mediator 패턴의 구현에는 별다른 테크닉이 필요없습니다. 참여하는 객체들이 RMI 인터페이스를 만족하도록 만들면, 쉽게 네트워크 응용으로 이식할 수도 있습니다. (물론 자바의 경우에 그렇다는 거죠 ㅋㅋ) 다만 이런 식으로 구현하게 되면 Mediator 클래스에 구현되는 메소드의 개수가 증가하게 된다는 문제는 있을 수 있습니다. 하지만 메소드 각각의 구현을 좀 더 쉽게 가져갈 수 있다는 장점이 있죠.

메소드 개수가 증가하는게 싫어서 Observer 패턴과 유사한 방식으로 통신 인터페이스를 단순화시키게 되면, Mediator 패턴 같은 경우에는 참여하는 객체들의 역할이 다 제각각이라서 각각의 객체 안에 메시지 파싱을 위한 로직을 추가해야 하는 부담이 생길 수 있습니다. 결국 객체간 통신을 위해 필요한 코드가 너무 늘어나게 되고, 결국 성능이 저하하게 될 수도 있어요.

자. 그런 trade-off에 대한 판단은 읽는 분들의 몪으로 남기고, Mediator 패턴에 대한 설명은 이것으로 접도록 하겠습니다.