í´ë¦°ìíí¸ì¨ì´ Part 6. ETS ì¬ë¡ ì°êµ¬

비지터 패턴

클래스 계층 구조에 새로운 메소드를 추가할 필요가 있지만, 그렇게 하는 작업은 고통스럽거나 설계를 해치게 된다.

디자인 패턴의 비지터 집합

타입 계층 구조를 변경하지 않고도 새로운 메소드를 계층 구조에 추가할 수 있음

비지터(Visitor)
비순환 비지터(Acyclic Visitor)
데코레이터(Decorator)

비지터 패턴 상세

이중 디스패치(dual dispatch) : 실행되는 연산이 요청의 종류와 두 수신자의 타입에 따라 달라진다는 뜻

비지터 패턴 클래스 다이어그램

비지터 패턴 클래스 다이어그램

비지터 패턴 시퀀스 다이어그램

비지터 패턴 시퀀스 다이어그램

연산의 변화 vs 구조의 변화

새로운 구상체가 계속 추가된다면 Visitor은 독이 된다.
새로운 연산이 계속 추가된다면 Vistor은 좋은 선택이다.

비순환 비지터 패턴

down-casting가 있어서 쓰기가 꺼려진다.
- 타입안정성이 약해짐
만약 generic을 이용할 수 있다면 더 낫지 않을까?

public void accept(ModemVisitor v) {
    try {
        ErniedModemVisitor ev = (ErnieModemVisitor) v;  // !!!
        ev.visit(this);
    } catch (ClassCastException e) {
    }
}

p.505 ErnieModem.java 일부

데코레이터 패턴

소리나는 다이얼 모뎀을 만들고 싶다

OCP, SRP 원칙을 지킬려면 어떻게 해야할까?
데코레이터!!!

public class LoudDialModem implements Modem {
    private Model modem;

    public LoudDialModem(Modem m) {
        this.modem = m
    }
    public void dial(String pno) {
        modem.setSpeakerVolume(10); // 데코레이팅!!!
        modem.dial(pno)
    }
    ...
}

확장 객체 패턴

아답터 패턴과 유사하다.
단점은 역시나 많은 subclass를 동반하는 것이다.
장점은 OCP와 SRP를 지킬 수 있다

확장 객체 패턴 클래스 다이어그램

확장 객체 패턴 클래스 다이어그램

참고 : The Extension Objects Pattern.pdf

스테이트 패턴 유한 상태 오토마타의 개괄

유한 상태 기계 : Finite State Machine

ex) 개찰구

개찰구 상태 다이어그램

개찰구 상태 다이어그램

구현기법 : 중첩된 switch/case

switch (state) {
    case LOCKED :
        switch (event) {
            case COIN :
                state = UNLOCKED;
                turnstileController.unlock();
                break;
            case PASS :
                turnstileController.alarm();
                break;
        }
        break;
    case UNLOCKED :
        switch (event) {
            case COIN :
                turnstileController.thankyou();
                break;
            case PASS :
                state = LOCKED;
                turnstileController.lock();
                break;
        }
        break;
}

turnstile : 개찰구

접근제어가 패키지인 상태변수

ISSUE 테스트를 진행할려면 테스트에서 상태를 변경할 수 있어야 한다.

이를 위해서 같은 패키지에서 만들어지는 테스트를 위해서 상태 변수를 패키지 접근제어로 변경하였다.
effective-java에 의하면 패키지 접근제어도 캡슐화가 깨지지 않는 것으로 보이므로 큰 문제가 없다고 판단되며, 본인도 종종 이것을 애용하는 편이다.
- 하지만 가능했다면, 패키지 생성자나 패키지 setter 메소드로 조금 더 제한하면 좋을 것 같다.
만약 C++이었다면 friend로 해결가능했을 것이다.

중첩된 switch/case의 장단점

간단한 상황에서는 가독성이 높고 효율적
복잡한 상황에서는 가독성이 떨어지고 유지보수도 어려워지며, 실수에 취약하다.
- 중복코드도 많이 생긴다.

구현기법 : 전이 테이블 해석

// 테이블 구축
public Trunstile(TurnstileController action) {
    turnstileController = action;
    addTransition(LOCKED, COIN, UNLOCKED, unlock());    // 마지막 메서드는 람다식으로 하면 더 나을 것 같다.
    addTransition(LOCKED, PASS, LOCKED, alarm());
    addTransition(UNLOCKED, COIN, UNLOCKED, thankyou());
    addTransition(UNLOCKED, PASS, LoCKED, lock());
}
...
// 전이 엔진
public void event(int event) {
    for (Transition transition : transitions) {
        // 아래 분기문은 transition의 메서드로 분기하면 좋을 것 같다.  : transition.isTransferable(state, event)
        if (state == transition.currentState && event == transition.event) {
            state = transition.newState;
            transition.action.execute();
        }
    }
}