게임 개발에 자주 사용되는 디자인 패턴
- 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에서도 사용되어 여러 번 테스트를 거쳤기 때문에 신뢰도가 높다.