본문 바로가기
개발일지/아키텍트

GoF, Command 패턴

by 사악신 2012. 2. 8.
책의 내용을 요약하여, Command 패턴의 마인드맵을 그려보았다.


클래스 다이어그램으로 표현하면,



만약, 어떤 기능을 수행하는 클래스 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

댓글