7. Command Pattern

문제

사용 객체의 API가 서로 다름

 

해결 방안

실행과 요청을 분리

 

목적

- 요구사항(요청, 명령)을 객체로 캡슐화 시킴

- 이를 이용해 다른 요구사항을 지닌 클라이언트를 매개변수화 시킬 수 있음.

- 요구사항을 큐에 넣거나 로그로 남길 수 있으며 작업 취소(undo) 기능 지원도 가능

 

결과

(작은)클래스가 많아지나, 객체 사용에 필요한 복잡성을 제거하고 감춘다(함수 이름이 동일해진다)

 

설계

*Decoupling : 요청과 실행을 분리

 

Command

 -Receiver를 알고 있고, Receiver의 method를 호출

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

 ex)Command, ConcreteCommand

 

Receiver

 - 실제 명령(command)수행

 

Invoker

 -요청을 받아 그것을 실행하기 위해 Command interface 연결.

 - Command interface만 알고 있으며, Command가 실제 어떻게 실행되는지 모른다.

 

Client

 -무엇을 요청할 지 결정하고, 요청 Command를 Invoker에 넘김

 

 

ex) Command 의 명령 : 교실을 청소해라

청소해 -> 바닥 닦는 사람을 바닥만 닦는다

          -> 칠판 당번은 칠판만 지운다 

 

*strategy는 동일 목적에 사용 방법이 다양함. ex)칠판 지우는 방법이 다양.

 

커맨드 객체

-일련의 행동을 특정 리시버와 연결시킴으로써 요구사항을 캡슐화 한것.

 

-행동과 리시버를 한 객체에 집어넣고, execute()라는 method 하나만 외부에 공개

   (excute 함수만 호출하면 내부에서 알아서 처리해주는 방식)

 

- 메소드 호출을 통해 리시버에서 일련의 작업들이 처리됨

 

-외부에서 볼 때에는 어떤 객체가 리시버 역할을 하는지,

  그 리시버에서 실제로 어떤일을 하는 지 알 수 없다.

 그냥 method execute()를 호출하면 요구 사항이 처리된다는 것만 알게 됨.

 

 

 

 

ex) Invoker는 특정 인터페이스만 구현되어있다면 

command 객체에서 실제로 어떤 일이 일어나는지 몰라도 된다.