* 오브젝트끼리의 디커플링

* 메세지(이벤트)를 보낸사람이 누구인가는 중요하지 않다.
* 네트워크에서오던, 로컬에서오던 똑같은 프로토콜로 통신하고 그냥 받아서 처리만 한다.

* 쓸데없는 게임 매니저 잔뜩 만들어놓지 않아도 됨

* 온라인/싱글간에 전환이 쉽다.

* 목업 만들기 쉽다.

* 이벤트를 시간순대로 출력하면 그 자체로 액티비티 로그가 완성됨

* 이벤트의 순서와 값들을 살펴보면 어디부터 잘못 흘러가는지 알 수 있어 디버깅이 용이

* 리플레이 제작이 용이, 그냥 이벤트 시간순대로 로컬에서 다시쏘면 코드 변경 없이 리플레이 됨

* 내부적으로만 사용되지만, 외부에서 불르기는 해야하기때문에 무조건 public 으로 만들어야만 했던 메소드들을 완벽하게 숨길 수 있음.

* 잘못된 씬 또는, 없는 오브젝트에 패킷을 배달할일이 없음.

* 오브젝트가 스스로 동작하는 능동적인 모델링 가능

* 기존에 게임 프로그래밍 방법들은 지나치게 수동적,
* 매니저라는놈을 만들어놓고, 그게 무슨 가혹한 하사관처럼 하위 오브젝트를 다 부린다.
* 근데 알아서 일하게 만들수있음




버튼이 눌리면 일시정지 처리를 수행하는 과정의 예제

가장 원시적인 방법,
버튼 클릭 핸들러가 모든 오브젝트에 일일히 명령을 내린다.


아마도 가장 많이 쓰이는 방법
게임 매니저라는 객체를 하나 두고, 명령을 대신 내려달라고 부탁한다.


구독받는 오브젝트가 늘어나면 GameManager와 오브젝트 양쪽을 다 수정해야한다.


메세지 기반의 방법
메세지를 전달할때는 PubSub 센터(게임 매니저와 비슷한 역할)에 전달하지만
수신할때는 구독만 등록할 뿐 PubSub으로부터 직접적으로 받지는 않는다.


구독이 늘어날 경우
오브젝트가 스스로 PubSub 센터에 구독을 요청하므로 오브젝트쪽에서만 수정하면 된다.


Posted by pjc0247