state 패턴

 

 

 

 

 

각 상태 정보를 클래스화해서 상태에 따른 행동을 만들어 놓는 것

 

=> 상태에 따라 행위를 변경해야 할때

 

일반적 관리를 위해 ABC 가 필요

 

 

 

멀티 쓰레드에서도 유리

 

 

 

---

 

 

각 상태를 나타내는 클래스들이 데이터 멤버를 가지지 않는다면 이들은 공유될 수 있다

 

객체 내부에 데이터 멤버가 없으면 객체는 동일한상태 ==> 서로간의 구분이 필요 없음

 

공유는 Flyweight , 또는 singleton 으로 구현 가능

(구조는 Flyweight 와 singleton 이 유사하다)

 

---

 

 

상태전환(객체를 누가 바꿀 것인가)

 

1. 클라이언트가  기준에 의해서 상태를 바꿔주는 것

    상태 전환 표에 따라 변환되게 할 수 있지만 , 새로운 상태가 추가 되면 상태표를 다시 고처줘야 한다

    상태객체관리가 보다 쉽다(상태 객체 추가 정도만 하면 되므로)

 

2. 각 상태 객체에서 각 상태가 끝나면 상태 객체에서 다음 상태를 반환

   이때는 각 상태간의 상태를 알아야 하는 상황이 올 수 있으므로 다른 상태 클래스를 추가할 경우 기존 것을 고처야 할 수 도 있다

   대략 mediator , observer 패턴을 연동해본느 것도 아이디어일 수 있다

 

둘다 장단점이 있음

 

 

---

 

상태 객체 삭제:

 

1. 상태가 공유되는 경우 공유되는 객체에 대한 레퍼런스 카운트를 두어 참조하는 객체가 없으면 소거한다

 

 

2. 필요 없는 상태객체 삭제 => A 객체에서 B 객체 즉 A 상태에서 B 상태로 갈때 A 의 포인터를 가지고 있는

 

    statepointer 를 delete statepointer ; 한 후  B 를  statepointer = new B 한다

 

    상태변환이 적은 경우 유용

 

 

 

---

 

 

10000명의 플레이어가 있다

캐릭터의 능력레벨이 20단계로 나뉘어진다고 가정하고 각 레벨마다 사용할 수 있는 것이 다르다고 한다, 하지만 중복되는 상태가 있을 수도 있다고 할대

20 단계 이상의 레벨을 추가 또는 삭제 할 수 있는 설계는?

 

=> 먼저 레벨들을 클래스로 만든 후, 1명 마다 각각 상태를 갖으면 낭비가 심함으로 공유되는 상태를 위해 Flywieght 패턴을 적용 할 수 있는데

    각 레벨의 특성마다 클래스가 다름으로 능력레벨에 대한 Abstract Base Class 를 두어 하나로 묶은 후 레벨 추가 삭제가 보다 간편해지게 하고

    유저는 상단 클래스의 포인터를 가지고 있으면 보다 효과 적이다

 

공유한다는 것은 각 레벨 클래스를 한번만 생성해놓고 다른 것들(다른 플레이어들)이 참조한다는 것