HTTP요청은 요청자와 처리자가 구분되어있다.
요청정보를 포함한 객체를 요청자에서 처리자로 전송하면 이를 처리하고, 응답을 반환하는 식으로 동작한다.
이는 중복되는 코드작성을 막아주므로 요청자의 코드관리에 도움이 되는 방식이다.
커맨드 패턴도 이와 유사하게 동작한다.
하나의 루트 클래스에서 분화되는 서브 클래스들 각각에 직접 동작을 작성하는 것이아니라, Command
객체를 생성하여 작업을 처리한다.
요청자에 해당하는 클래스에서 Command
객체를 생성하고, 그 객체안에는 작업의 실행코드를 작성하는 것이다.
이렇게되면 서브클래스에 중복되던 코드를 줄이고 클래스유형에 상관없이 동작단위로 클래스를 관리할 수 있다.
Command
인터페이스를 이용하여, 이를 구현하는 세부 Command
클래스들을 생성하고 필요에 따라 해당하는 객체를 전달하는 것이다.
클래스 구조도를 확인해보면 Command
인터페이스에는 하나의 실행 메서드인 excute()
만이 존재한다.
이를 구현하는 세부 클래스에는 Command
를 받을 대상자와 파라미터 값을 생성자로 입력받는다.
Invoker
를 이용해서 실행할 Command
객체를 지정한 뒤에 실행메서드를 동작시키면,
Reciever
에게 파라미터가 전달되고 실제 작업이 이뤄진다.
포스팅 자체가 Refactoring Guru 사이트에 기반을 두고있으므로, 해당 사이트에 소개된 예시 구조도를 가져왔다.
실행된 작업 기록을 추적하고, 되돌리는게 가능하다는 것을 파악할 수 있다.
앞선 설명에서의 클래스 구조도와 비교해서 각각의 클래스를 살펴보면 아래와 같다
Application
:Invoker
역할Editor
:Receiver
역할Buttons
,Shortcuts
:Client
역할
동작하는 과정은 대략적으로 아래와 같다.
Application
의 createUI()
를 통해 Buttons
과 Shortcuts
설정Command
객체를 생성하여 등록Command
객체와 관련된 버튼 혹은 단축키 실행excuteCommand()
에 Command
객체 전달 및 실행Editor
에 Command
동작이 실행됨CommandHistory
를 이용해 과거기록을 관리