[게임 프로그래밍 패턴] 14. 이벤트 큐 패턴

이벤트 큐 패턴 (Event Queue Pattern)

281 : 메시지나 이벤트를 보내는 시점과 처리하는 시점을 디커플링한다.

이벤트 큐 패턴

큐는 요청이나 알림을 들어온 순서대로 저장한다. 알림을 보내는 곳에서는 요청을 큐에 넣은 뒤에 결과를 기다리지 않고 리턴한다. 요청을 처리하는 곳은 큐에 들어 있는 요청을 나중에 처리한다. 요청은 그곳에서 직접 처리될 수도 있고, 다른 여러 곳으로 보내질 수도 있다. 이를 통해 요청을 보내는 쪽과 받는 쪽을 코드뿐만 아니라 시간 측면에서도 디커플링한다.

언제 쓸 것인가?

메시지를 보내는 시점과 받는 시점을 분리하고 싶을 때 사용한다. 보내는 쪽에서 처리 응답을 받지 않아도 될 때 유용하다.

주의사항

1. 중앙 이벤트 큐는 전역 변수와 같다.
   - 이벤트 큐는 모든 게임 시스템에서 서로 메시지를 주고 받는 복잡한 중앙역 같은 역할로 사용된다. 중앙 이벤트 큐를 간단한 프로토콜로 깔끔하게 래핑하지만, 그래도 전역이다 보니 전역 변수에 관련된 문제가 존재한다.
2. 월드 상태는 언제든 바뀔 수 있다.
   - 이벤트를 받았을 때는 현재 월드 상태가 이벤트가 만들어진 당시 상태와는 다를 수 있다는 점을 주의해야 한다.
3. 피드백 루프에 빠질 수 있다.
   - 메시징 시스템이 큐 시스템인 경우 비동기다보니 콜스택이 풀려서 루프에 빠질 수 있다. 이벤트를 처리하는 코드 내에서는 이벤트를 보내지 않는 것이 일반적인 규칙이다.

구현 방법

1. 배열 또는 원형 버퍼로 큐를 만든다.
2. 출력 요청들을 큐에 저장해둔다.
3. 업데이트 시 출력 요청들을 순회하며 요청을 처리한다.

디자인 결정

1. 큐에 무엇을 넣을 것인가?
   1. 큐에 이벤트를 넣는 경우
      - 복수 개의 리스너를 지원해야 할 때도 많다.
      - 큐의 범위가 더 넓은 편이다.
   2. 큐에 메시지를 넣는 경우
      - 대부분은 리스너가 하나다.
2. 누가 큐를 읽는가?
   1. 싱글캐스트 큐
      - 큐는 밖에서는 보이지 않는 내부 구현이 된다.
      - 큐가 더 캡슐화되어 있다.
      - 리스너 간에 경쟁을 고민하지 않아도 된다.
   2. 브로드캐스트 큐
      - 이벤트가 무시될 수 있다.
      - 이벤트 필터링이 필요할 수 있다.
   3. 작업 큐
      - 작업을 분배해야 한다.
3. 누가 큐에 값을 넣는가?
   1. 넣는 측이 하나라면
      - 어디에서 이벤트가 오는지를 암시적으로 안다.
      - 보통 리스너가 여러 개다.
   2. 넣는 측이 여러 개라면
      - 이벤트 순환을 주의해야 한다.
      - 이벤트를 보낸 객체에 대한 레퍼런스를 이벤트에 추가해야 할 필요가 있을 수 있다.
4. 큐에 들어간 객체의 생명주기는 어떻게 관리할 것인가?
   1. 소유권을 전달한다.
   2. 소유권을 공유한다.
   3. 큐가 소유권을 가진다.