서론
앞으로 만들 Job 혹은 Task를 관리하는 Queue가 결국에는 전형적인
커맨드 패턴의 예제이기 때문에 잠시 짚고 넘어가는 시간을 가진다
식당 예제
다시 식당 예제로 돌아와서
클라이언트가 주문을 하려고하면 클라이언트 세션에 주문을 한다
그럼 서빙담당 직원이 가서 주문을 받아서 뭔가 처리를 해야한다
현재 상황은 서빙을 받자마자 해당직원이 주방에 달려가서 요리를하는게 지금 우리가 지금까지 만든 코드다 즉, 클라 세션이 요청을하면 서버가 직접 PacketHandler에서 직접적으로 코드 처리를 해주고있었다
결국 그게 식당 예제에서는 서빙하는 직원이 주방에 들어가서 손님이 요청한거를 만든다는것이다
이게 작은 식당이면 문제가없다 실제로 작은 식당은 사장님이 주방도 정리하고 서빙도 하신다
근대 이게 식당이 커지면 문제가 생긴다 즉, 직원이 서빙을 하고 음식 만드는 것도 한다고 치자 근대? 여기서 추가 조건으로 주방이 작은데 직원은 많다면? 직원들은 주문을 받으면 조리 하는것까지 기다려야 한다
어느 한 직원의 사이클은 서빙 → 조리 → 서빙 → 조리 순이다 이 얘기는 꼭 조리가 끝나야지 주문을 받을 수 있단 소리다 그러면 너무 비효율적이지 않나?
그래서 주방일 하는 직원 따로 두고 서빙일 하는 직원을 따로 둬서 굴려보면 어떨까? 라는 이야기로 흘러 들어간다
즉, 이러한 방법이 커맨드 패턴과 굉장히 유사하다고 생각 할 수 있다 어떠한 요청이 들어왔을 때 바로 처리하는게 아니라 중간 단계를 하나 거치는 주문서같은 개념을 만들어서 요리하는 사람이 똑같이 요청한 사항을 요리할 수 있게 만드는것이 커맨드 패턴
장점 :
- 주문이 오는것과 주문을 받아가지고 음식을 만드는 시점을 둘로 분리할 수 있다는 점
- 요리가 진행이 안되었다면 손님이 마음이 바뀌어서 주문을 취소하거나 주문을 바꾼다거나 할 수있다 (큐에 들어가 있는 상태라면) 추가 : (우리가 게임을 만들 때 뭔가 어떤 요청을 취소하는 상황이 발생 즉 Undo같은 개념이 들어간다면 커맨드 패턴에서도 괜찮다)
인터넷 자료에 나와있는 커맨드 패턴 (위키 백과)
커맨드 패턴(Command pattern)이란 요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 매서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴이다.
커맨드 패턴에는 명령(command), 수신자(receiver), 발동자(invoker), 클라이언트(client)의 네개의 용어가 항상 따른다. 커맨드 객체는 수신자 객체를 가지고 있으며, 수신자의 메서드를 호출하고, 이에 수신자는 자신에게 정의된 메서드를 수행한다. 커맨드 객체는 별도로 발동자 객체에 전달되어 명령을 발동하게 한다. 발동자 객체는 필요에 따라 명령 발동에 대한 기록을 남길 수 있다. 한 발동자 객체에 다수의 커맨드 객체가 전달될 수 있다. 클라이언트 객체는 발동자 객체와 하나 이상의 커맨드 객체를 보유한다. 클라이언트 객체는 어느 시점에서 어떤 명령을 수행할지를 결정한다. 명령을 수행하려면, 클라이언트 객체는 발동자 객체로 커맨드 객체를 전달한다.
구조 (위키 백과 참고)
참고 링크 : https://ko.wikipedia.org/wiki/%EC%BB%A4%EB%A7%A8%EB%93%9C_%ED%8C%A8%ED%84%B4