게임 개발에 자주 사용되는 디자인 패턴

스테이트 패턴 (state pattern)

-정의 - 객체가 상태를 가지고 있고 현재 상태에 따라 행동이 달라지는 것을 말한다.

– 어떤 클래스(=객체)는 할 수 있는 행동이 정해져 있고 객체의 상태에 따라 행동이 달

라진다.

-예제

FSM(Finite State Machine)

-정의 – 유한 상태 기계 -> 유한한 개수의 상태들로 구성된 간단한 기계

- 하나의 입력을 받고 그에 대해 “현재 상태에서 다른 어떤 상태”로 전이

- 게임의 기본 AI에 사용

-특징 – 유한 수의 상태를 가진다.

- 자신의 상태를 시험할 수 있다. (?)

- 외부로부터 입력을 받는다.

- 이산된 시간의 단계에 그 자신의 상태를 변화 시킬 수 있다.

- 자신의 상태와 외부의 입력에 근거한 일단의 규칙에 따라 자신의 상태를 변화시킬 수

있다.

-예제

<유한 수의 상태>

대기 탐색 전투

도주 공격

<상태 전이>

*FSM 과 State Pattern

-얼핏 보면 FSM 과 State Pattern 은 비슷해 보인다.

-FSM 은 완성품이라면 State Pattern 은 완성품을 만들 기술

-FSM 은 if else 를 이용해 만들 수도 있다.

대기

탐색

전투

도주 공격

적을 찾기 위해

탐색상태로 전환

탐색 중에 적을 발견

전투 상태로 전환

도주를 성공하거나

이기면 대기 상태로

전환

옵저버 패턴 (Observer Pattern)

-정의 – 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들(observers)에게 전해지고

자동으로 내용이 갱신되는 일대 다(one-to-many) 양식의 패턴

-특징 – 데이터의 주체인 ‘subject’를 통해서 여러 객체의 데이터에 접근해서 보다 깔끔한 객체

프로그래밍을 할 수 있다.

- ‘observer ’와 ‘observer ’ 혹은 ‘observer’와 ‘subject’ 관계를 느슨하게 만들어 준다.

- 각각이 바뀌어도 서로에게 영향을 주지 않는다.

- 새로운 형식의 ‘observer ’가 와도 ‘subject’는 바꾸지 않아도 된다.

- ‘observer’는 언제든지 새로 추가할 수 있다.

- ‘subject’와 ‘obeserver’는 각각 독립적으로 재사용이 가능하다.

-예제

옵저버 패턴을 구현하기 위해 Observer 에는 여러 가지가 있을 수 있는 다는 것을 고려하여 미리

Observer 라는 인터페이스를 생성하여 이것을 상속받도록 하였다.

Subject 는 각각의 Observer 의 정보를 알 필요가 없다. 그렇기 때문에 Subject 는 공통으로 사용

될 인터페이스와 Observer 의 등록, 해제 함수만 가지고 있으면 된다.

->결과

비지터 패턴 (Visitor Pattern)

-정의 – 기존 객체 지향 프로그래밍에서 객체가 자신의 오퍼레이션을 가지고 있던 반면

‘비지터 패턴’은 객체의 구조와 기능을 분리 시키는 패턴이다.

- 객체의 구조는 변하지 않고 기능만 따로 추가, 확장 시켜야 할 때 사용

- 비객체 지향 특성을 가진다. 하지만 이를 통해 유연한 객체 지향 프로그래밍을 할 수

있다.

-언제 사용하는가?

- 객체 구조는 이미 짜여 있는 데 그 객체에 적용되어야 하는 오퍼레이션이 정해져 있지

않아서 객체의 오퍼레이션을 줄 수 없을 때

- 자주 변경 될 메소드가 존재할 때

- 객체 -> Element 오페레이션 -> Visitor

- Element 의 적용되어야 할 메소드는 Visitor 에 정의 되어 있다.

- Elemnet 가 Visitor 의 메소드를 사용할 때 Element 에게 Visitor 를 넘겨 준다. (visitor

pattern)

-예제

-Element 로 Color 추상 클래스 선언

-Visitor 의 메소드를 호출할 때 Visitor 를 받기 위한 accept 함수를 만든다.

-CountVisitor 클래스를 통해 Element 가 Accept 했을 때 Visit 함수에 몇 번 호출 되었는지 센다.

-CallVisitior 클래스를 통해 기존의 Element 내부에 있는 다른 객체에서 Visitor 를 accept 했을 때

CallVistitor 의 visit 를 호출하여 메소드를 호출하는 구성이다.

->결과

Composite Pattern

-정의 – 객체(혹은 클래스)를 트리구조로 구성한다.

- 추상적인 상위 클래스를 하나 만들고 그 클래스를 상속 받는 개별 객체와

복합객체(composite)를 만든다.

- 개별 객체는 실제 사용되는 말단 객체, 복합 객체는 또 다른 객체의 집합을 구성하는

상위 객체

- 클라이언트에서는 두 객체를 마치 같은 종류의 클래스 다루듯이 사용할 수 있다.

-특징 – 클라이언트를 단순화 시킨다.

- 복합객체를 사용하는지 개별 객체를 사용하는지 신경 쓰지 않아도 된다.

- 새로운 종류의 추상 클래스를 쉽게 추가할 수 있다.

- 지나치게 범용적인 디자인이 될 수도 있다. (주의)

-예제

<트리구조 클래스>

<코드>

-최상위 Component class

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

-Component 에서 상속 받은 Composite class

-Leaf 객체를 담기 위한 함수를 가지고 있다

-Leaf 에 대한 관리와 행동을 정의한다.

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

CBD(Component Based Development)

-정의 – 컴포넌트 기반 개발

- 시스템을 하나의 일체형으로 구축하지 않고 레고 블록처럼 요소들을 부품화한다.

-특징 – 소프트웨어의 생산성을 높인다.

- 이미 사용되고 있는 컴포넌트는 다른 SW 에서도 사용되어 여러 번 테스트를 거쳤기

때문에 신뢰도가 높다.