[Head First Design Patterns] 06 커맨드 패턴

(본 강의 노트는 한빛 미디어의 [Head First Design Patterns]책을 기반으로 하고 있습니다)

 

06 커맨드 패턴

Command Pattern

목적

- 요구사항(요청, 명령)을 객체로 캡슐화시킴. 이를 이용해서 다른 요구사항을 지닌 클라이언트를 매개변수화 시킬 수 있고, 요구사항을 큐에 넣거나 로그로 남길 수 있으며 작업 취소(undo) 기능을 지원할 수도 있음

요소	설명
이름	커맨드(Command)
문제	사용 객체의 API가 서로 다름
해결방안	실행과 요청을 분리
결과	작은 클래스가 많아지지만, 객체 사용에 필요한 복잡성을 제거하고 감춤(함수 이름이 동일해짐)

커맨드 패턴 클래스 다이어그램

 

문제(1) - 홈오토메이션용 리모컨

1. 사용하려는 객체가 많고, API가 서로 다른 경우

- 차고문 up()

- on()

- TV pressOn()

- and so on ...

 

2. 예로, 해당 리모컨 개발 시 차고문, 전등, TV, Stereo, 에어컨 등 사용해야 하는 객체가 너무 많고 서로 다른 명령들로 구성되어 있음

문제(2) - 객체마을 식당

1. 식당에서 주문

- 고객이 종업원에게 주문함

- 종업원이 주문을 받아 카운터에 갖다 주고 "주문 받아요!"라고 주방장에게 얘기함

- 주방장이 주문대로 음식을 준비함

 

2. 객체와 메소드로 표현

*waitron : 웨이터, 웨이트리스를 통칭한 표현

Order

- 주문한 메뉴를 요구하는 역할

- 웨이트런이 계산대 또는 다른 웨이트런에게 전달 가능

- orderUp()이라는 인터페이스가 포함되어 있음 : 식사를 준비하기 위한 행동을 캡슐화한 메소드

- 주방장(chef)에 대한 레퍼런스가 포함될 수 있음

 

Waitron

- 손님에게 주문 받고 orderUp() 메소드를 호출하여 식사 준비를 시키는 역할

- Order에 무슨 내용이 있는지 누가 식사를 준비하는지 알 필요 없음

- takeOrder() 메소드 포함(여러 클라이언트, 여러 오더를 전달)

 

Chef

- 식사를 준비하는 방법을 알고 있음

- 웨이트런과 분리되어 있음

- 웨이트런은 각 주문서에 있는 orderUp()을 호출하고 Chef는 Order로부터 할 일을 전달 받음

 

* 여기서는 어떤 것을 요구하는 객체와 그 요구를 받아들이고 처리하는 객체를 분리시킴

* 리모컨 API에서 리모컨 버튼이 눌렸을 때 호출되는 코드와 특정 업체에서 제공한, 실제로 일을 처리하는 코드를 분리시키는 것이 필요함

 

설계

Decoupling : 요청과 실행을 분리

Object	설명	레스토랑	리모컨
Client	커맨드 객체 생성	Client	리모컨 버튼의 기능을 인지하고 버튼 누름
Command (커맨드)	어떤 Receiver를 실행할 지 연결	Order	버튼에 실제 사용 객체를 연결해놓음
Invoker	주문을 받아서, 실행하기 위해 Command 인터페이스 연결	Waitron	리모컨 버튼을 누르면 기능을 실행함
Receiver	실제 명령을 수행	Chef	TV, 전등 같은 실제 객체

Command

- Receiver를 알고 있고, Receiver의 메소드를 호출

- Receiver의 메소드에서 사용되는 매개변수의 값들은 Command에 저장됨

- 예: Command, ConcreteCommand

Receiver

- 실제 명령(Command) 수행

- 예: Light, GarageDoor

 

문제(2) - 객체마을 식당과 커맨드 패턴