관찰자(Observer) 패턴

관찰자 패턴은 GoF 패턴 중에서도 가장 널리 사용되고 잘 알려졌지만,
세상을 등지고 살아가는 게임 개발자에게는 생판 처음 듣는 이야기일 수도 있다.

{ 관찰자 패턴이란? }

관찰자 패턴은 GoF의 행위 패턴 중 하나로,

한 객체의 상태가 변화하면 객체에 관찰자로 등록되어 있는 다른 객체들에게 변화된 상태를 전달하는 패턴이다.

주로 분산 시스템 간에 이벤트를 생성•발생(Publish)하고, 이를 수신(Subscribe)해야 할 때 이용한다.

• 관찰자 패턴은 MVC(Model View Controller) 구조의 기반이다.
• 자바의 EventListener나 C#의 delegate와 같이 같은 모던 OOP 언어에서는 자체적으로 관찰자 패턴을 지원한다.

{ 게임 개발에서 관찰자 패턴 활용하기 : 업적 시스템 }

메이플스토리 업적 (출처 - https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=adoll21&logNo=221343569529)

게임 업적은 종류가 많고 그만큼 달성할 수 있는 방법이 다양해서 깔끔하게 구현하기 어렵다.

 

예를 들어 '다리에서 낙하하기'라는 업적이 있다고 하자.
물리 엔진 한 가운데에 UnlockFallOffBridge() 함수를 호출하는 끔찍한 짓을 하고 싶은 프로그래머는 없을 것이다. 

 

이때 사용할 수 있는 것이 관찰자 패턴이다.
관찰자 패턴을 적용하면 어떤 코드에서 특정 이벤트가 발생했을 때 누가 받은 상관없이 알림을 보낼 수 있다.

void Physics::updateEntity(Entity& entity) 
{ 

  bool wasOnSurface = entity.isOnSurface(); 

  entity.accelerate(GRAVITY); 

  entity.update();

  if(wasOnSurface && !entity.isOnSurface()) 
  { 
    notify(entity, EVENT_START_FALL);
  }

}

 

업적 시스템은 물리 엔진이 알림을 보낼 때마다 받을 수 있도록 스스로 등록한다.
업적 시스템은 물리 엔진이 보내오는 알림을 받으면 떨어지는 물체가 Player가 맞는지, Player가 떨어지기 전에 있던 곳이 다리인지 확인한 뒤에 업적을 잠금 해제한다.

 

이런 과정을 물리 엔진은 전혀 몰라도 된다.물리 엔진은 누가 받든 안받든 특정 조건에서 계속 알림을 보낼 뿐이다.

이렇게 관찰자 패턴을 사용해 물리 엔진과 업적 시스템의 커플링을 해소할 수 있다.

{ 관찰자 패턴 인터페이스 }

1. 관찰자(Observer)

Observer 클래스는 이벤트를 수신하는 클래스이다. Observer 클래스의 인터페이스는 다음과 같다.

**언어에 따라서 제네릭(generic) 혹은 템플릿 같은 걸 써도 되지만, 그냥 필요에 맞게 원하는 자료형을 전달해도 된다. 여기에서는 게임 개체와 무슨 일이었는지를 설명하는 열거형 값을 하드코딩해서 넣었다.

class Observer 
{

  public: virtual ~Observer() {}

  virtual void onNotify(const Entity& entity, Event event) = 0;

};

어떤 클래스든 Observer 인터페이스를 구현하기만 하면 관찰자가 될 수 있다. 예시로 설명한 업적 시스템은 다음과 같이 구현될 수 있다.

class Achievements : public Observer 
{ 

public:
  virtual void onNotify(const Entity& entity, Event event) 
  { 
    switch (event) 
    {

      case EVENT_ENTITY_FELL:
        if(entity.isHero() && heroIsOnBridge_) 
        { 
          unlock(ACHIEVEMENT_FELL_OFF_BRIDGE);
        }
        break;

        // 그 외 다른 이벤트를 처리하고...

        // heroIsOnBridge_ 값을 업데이트한다...
    }
  }

private:
  void unlock(Achievement achievement) 
  {

    // 아직 업적이 잠겨 있다면 잠금해제한다...

  }

  bool heroIsOnBridge_;

};

2. 대상(Subject)

Subject 클래스는 알림 메서드를 호출하는 클래스이다.

• Subject 클래스 알림을 받을 관찰자 목록을 가지고 있으며, 누구든 관찰자로 등록되고 삭제될 수 있도록 API를 열어둬야 한다. 
• Subject클래스는 관찰자들에게 알림을 보낸다.

class Subject 
{
private: 
	Observer* 	m_Observers[MAX_OBSERVERs];
    int 		m_iNumOfObservers;
    
public:
	void AddObserver(Observer* _obs)
    {
    	// 배열에 옵저버 추가
    }
    
    void RemoveObserver(Observer* _obs)
    {
    	// 배열에 옵저버 삭제
    }

protected:
	void notify(const Entitiy& entitiy, Event event)
    {
    	for(const auto& o : m_Observers)
        {
        	o->onNotify(entity, event); 
        }
    }
    
}

Subject의 옵저버 컨테이너 개선하기

위 코드에서는 정적 배열을 사용하여 하여 관찰자들을 저장하였지만,

실제 프로젝트에서는 동적 배열을 사용할 가능성이 높다.

동적 배열을 사용하여 옵저버를 저장할 때 다음과 같은 문제가 생길 수 있다.

1. 잦은 동적 할당
2. 옵저버 추가, 삭제에 따른 비용

옵저버 컨테이너를 연결 리스트로 바꾸면 위의 문제를 해결할 수 있다.

1. 연결 리스트의 노드들을 Pool로 관리
   연결 리스트의 노드들은 모두 크기가 같기 때문에 미리 할당하여 Pool로 관리할 수 있다. 
   Pool로 노드들을 관리하면, 옵저버가 추가/삭제 될 때마다 동적 할당/해제를 하는 일이 없어져 잦은 동적 할당으로 인한 메모리 단편화나 속도 문제가 해결된다.
2. 리스트는 중간 값 삭제 비용이 O(1)이다.
   vector에 경우 중간 값을 삭제하면 데이터를 옮기는 과정이 일어나 O(n)의 시간이 걸리지만 리스트는 중간 값 삭제에 O(1)의 시간이 걸려 빠르다.

{ 주의할 점 }

1. 관찰자 패턴은 동기적임을 기억하자.

관찰자 패턴은 동기적이다.
대상(Subject)이 관찰자(Observer) 메서드를 직접 호출하기 때문에 모든 관찰자가 알림 메서드를 반환하기 전에는 다음 작업을 수행할 수 없다. 관찰자 중 하나라도 느리면 대상이 블록될 수도 있다. 

따라서 관찰자를 멀티 스레드, 락(lock)과 함께 사용할 때는 정말 조심해야 한다.

어떤 관찰자가 대상의 락을 물고 있다면 게임 전체가 교착상태에 빠질 수 있기 때문이다.

엔진에서 멀티 스레드를 많이 쓰고 있다면 이벤트 큐를 이용해 비동기적으로 소통하는 것이 좋다.

 

2. 사라진 관찰자에 알림을 보내지 않게 주의하자.

대상은 관찰자들의 포인터를 참조해 관찰자들의 메서드를 직접 호출하기 때문에,

대상이 메모리 해제된 관찰자에 접근해 메서드 호출을 시도하는 일이 발생하면 게임이 뻥-! 터질 수 있다.

따라서 관찰자의 소멸자에서 Subject::RemoveObserver(this) 를 꼭 호출해주자.

 

3. 가비지 컬렉션의 지원을 받더라도 더 이상 사용하지 않을 관찰자는 꼭 RemoveObserver()를 호출하자.

가비지 컬렉터의 지원을 받더라도 주의할 점이 있다.

더 이상 사용하지 않을 관찰자를 가비지 컬렉터가 자동으로 삭제할 것이라고 생각하고 방치하지 말자.

대상이 해당 관찰자를 참조하고 있는 한, 가비지 컬렉터는 해당 관찰자를 삭제하지 않는다.

이런 상황은 알림 시스템에서 굉장히 자주 일어나는 일로 '사라진 리스너 문제' 라는 이름까지 붙을 정도다.

그러므로 가비지 컬렉션의 지원을 받더라도 더 이상 사용하지 않을 관찰자는 꼭 RemoveObserver()를 호출하자.

 

 

reference

도서 : 게임 프로그래밍 패턴