책의 내용을 요약하여, Command 패턴의 마인드맵을 그려보았다.
클래스 다이어그램으로 표현하면,
만약, 어떤 기능을 수행하는 클래스 TReceiver 가 있다고 하자, 해당 기능을 사용하기 위하여 인스턴스를 생성하고 메소드 ActionA, ActionB 등을 호출할 것이다. 헌데, 이 기능들을 좀 더 복잡하게 사용(여러 UI 에서 접근, 기능의 조합, 매크로 기능, UnDo 기능 등..)해야하는 경우가 발생한다면 어떻게 해야할까? 애초 기능 그 자체를 클래스로 설계하거나, 기능 클래스를 정의한 뒤 실제 동작은 기존 기능을 처리하던 클래스에 위임해버리는 방법이 있을 것이다. 이때 후자를 Command 패턴이라고 한다. TInvoker 라는 놈은 기능 클래스들을 소유하고 호출하는 것으로 논리적인 개념으로 보면 된다.(TClient 에 흡수시켜버려도 되고 다른 패턴의 한 부분이 되기도 하고... 등등) 즉, 어떤 클래스가 TInvoker 의 역할이 되느냐를 고민하면 되겠다.
상기 TConcreteCommandA 의 Execute 메소드는 TReceiver 의 ActionA 를 호출하며, 당연한 이야기겠지만 TReceiver 의 인스턴스를 참조하고 있어야한다.
클래스 다이어그램으로 표현하면,
만약, 어떤 기능을 수행하는 클래스 TReceiver 가 있다고 하자, 해당 기능을 사용하기 위하여 인스턴스를 생성하고 메소드 ActionA, ActionB 등을 호출할 것이다. 헌데, 이 기능들을 좀 더 복잡하게 사용(여러 UI 에서 접근, 기능의 조합, 매크로 기능, UnDo 기능 등..)해야하는 경우가 발생한다면 어떻게 해야할까? 애초 기능 그 자체를 클래스로 설계하거나, 기능 클래스를 정의한 뒤 실제 동작은 기존 기능을 처리하던 클래스에 위임해버리는 방법이 있을 것이다. 이때 후자를 Command 패턴이라고 한다. TInvoker 라는 놈은 기능 클래스들을 소유하고 호출하는 것으로 논리적인 개념으로 보면 된다.(TClient 에 흡수시켜버려도 되고 다른 패턴의 한 부분이 되기도 하고... 등등) 즉, 어떤 클래스가 TInvoker 의 역할이 되느냐를 고민하면 되겠다.
상기 TConcreteCommandA 의 Execute 메소드는 TReceiver 의 ActionA 를 호출하며, 당연한 이야기겠지만 TReceiver 의 인스턴스를 참조하고 있어야한다.
반응형
'개발일지 > 아키텍트' 카테고리의 다른 글
Proactor with IOCP (4) | 2012.02.13 |
---|---|
POSA2, ACT 패턴 (0) | 2012.02.08 |
POSA, Forwarder-Receiver 패턴 (0) | 2012.01.31 |
POSA, Whole-Part 패턴 (0) | 2012.01.30 |
나의, UML 객체지향 설계 - 3 - (0) | 2011.12.20 |
댓글