게임 개발에 자주 사용되는 디자인 패턴 -스테이트 패턴과 FSM -옵저버 패턴과 비지터 패턴 -composite 패턴과 CBD

1. 스테이트 패턴 (state pattern)
-정의 - 객체가 상태를 가지고 있고 현재 상태에 따라 행동이 달라지는 것을 말한다.
– 어떤 클래스(=객체)는 할 수 있는 행동이 정해져 있고 객체의 상태에 따라 행동이 달 라진다.
-예제

5. FSM(Finite State Machine)
-정의 – 유한 상태 기계 -> 유한한 개수의 상태들로 구성된 간단한 기계
- 하나의 입력을 받고 그에 대해 “현재 상태에서 다른 어떤 상태”로 전이
- 게임의 기본 AI에 사용
-특징 – 유한 수의 상태를 가진다. - 자신의 상태를 시험할 수 있다. (?)
- 외부로부터 입력을 받는다. - 이산된 시간의 단계에 그 자신의 상태를 변화 시킬 수 있다.
- 자신의 상태와 외부의 입력에 근거한 일단의 규칙에 따라 자신의 상태를 변화시킬 수 있다.
-예제
<유한 수의 상태>
대기
탐색
전투
도주
공격

6. <상태 전이>
*FSM과 State Pattern
-얼핏 보면 FSM과 State Pattern은 비슷해 보인다.
-FSM은 완성품이라면 State Pattern은 완성품을 만들 기술
-FSM은 if else를 이용해 만들 수도 있다.
대기
탐색
전투
도주
공격
적을 찾기 위해
탐색상태로 전환
탐색 중에 적을 발견 전투 상태로 전환
도주를 성공하거나 이기면 대기 상태로 전환

7. 옵저버 패턴 (Observer Pattern)
-정의 – 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들(observers)에게 전해지고 자동으로 내용이 갱신되는 일대 다(one-to-many) 양식의 패턴
-특징 – 데이터의 주체인 ‘subject’를 통해서 여러 객체의 데이터에 접근해서 보다 깔끔한 객체 프로그래밍을 할 수 있다.
- ‘observer’와 ‘observer’ 혹은 ‘observer’와 ‘subject’ 관계를 느슨하게 만들어 준다.
- 각각이 바뀌어도 서로에게 영향을 주지 않는다.
- 새로운 형식의 ‘observer’가 와도 ‘subject’는 바꾸지 않아도 된다.
- ‘observer’는 언제든지 새로 추가할 수 있다.
- ‘subject’와 ‘obeserver’는 각각 독립적으로 재사용이 가능하다.

8. -예제

9. 옵저버 패턴을 구현하기 위해 Observer에는 여러 가지가 있을 수 있는 다는 것을 고려하여 미리 Observer라는 인터페이스를 생성하여 이것을 상속받도록 하였다.

11. Subject는 각각의 Observer의 정보를 알 필요가 없다. 그렇기 때문에 Subject는 공통으로 사용 될 인터페이스와 Observer의 등록, 해제 함수만 가지고 있으면 된다.

12. ->결과

13. 비지터 패턴 (Visitor Pattern)
-정의 – 기존 객체 지향 프로그래밍에서 객체가 자신의 오퍼레이션을 가지고 있던 반면 ‘비지터 패턴’은 객체의 구조와 기능을 분리 시키는 패턴이다.
- 객체의 구조는 변하지 않고 기능만 따로 추가, 확장 시켜야 할 때 사용
- 비객체 지향 특성을 가진다. 하지만 이를 통해 유연한 객체 지향 프로그래밍을 할 수 있다.
-언제 사용하는가?
- 객체 구조는 이미 짜여 있는 데 그 객체에 적용되어야 하는 오퍼레이션이 정해져 있지 않아서 객체의 오퍼레이션을 줄 수 없을 때
- 자주 변경 될 메소드가 존재할 때
- 객체 -> Element 오페레이션 -> Visitor
- Element의 적용되어야 할 메소드는 Visitor에 정의 되어 있다.
- Elemnet가 Visitor의 메소드를 사용할 때 Element에게 Visitor를 넘겨 준다. (visitor pattern)

14. -예제
-Element로 Color 추상 클래스 선언
-Visitor의 메소드를 호출할 때 Visitor를 받기 위한 accept 함수를 만든다.

16. -CountVisitor 클래스를 통해 Element가 Accept 했을 때 Visit 함수에 몇 번 호출 되었는지 센다.
-CallVisitior 클래스를 통해 기존의 Element 내부에 있는 다른 객체에서 Visitor를 accept 했을 때 CallVistitor의 visit를 호출하여 메소드를 호출하는 구성이다.

17. ->결과

18. Composite Pattern
-정의 – 객체(혹은 클래스)를 트리구조로 구성한다.
- 추상적인 상위 클래스를 하나 만들고 그 클래스를 상속 받는 개별 객체와 복합객체(composite)를 만든다.
- 개별 객체는 실제 사용되는 말단 객체, 복합 객체는 또 다른 객체의 집합을 구성하는 상위 객체
- 클라이언트에서는 두 객체를 마치 같은 종류의 클래스 다루듯이 사용할 수 있다.
-특징 – 클라이언트를 단순화 시킨다.
- 복합객체를 사용하는지 개별 객체를 사용하는지 신경 쓰지 않아도 된다.
- 새로운 종류의 추상 클래스를 쉽게 추가할 수 있다.
- 지나치게 범용적인 디자인이 될 수도 있다. (주의)
-예제
<트리구조 클래스>

19. <코드>
-최상위 Component class

20. -Component class에서 상속받는 Leaf class -> 실질적인 객체

21. -Component에서 상속 받은 Composite class
-Leaf 객체를 담기 위한 함수를 가지고 있다
-Leaf에 대한 관리와 행동을 정의한다.

22. -Component 하위 클래스인 composite 와 leaf 클래스 객체 생성 후 값을 넣어 사용한다.

23. CBD(Component Based Development)
-정의 – 컴포넌트 기반 개발
- 시스템을 하나의 일체형으로 구축하지 않고 레고 블록처럼 요소들을 부품화한다.
-특징 – 소프트웨어의 생산성을 높인다.
- 이미 사용되고 있는 컴포넌트는 다른 SW에서도 사용되어 여러 번 테스트를 거쳤기 때문에 신뢰도가 높다.