Unity 게임 디자인 패턴

1. Abstract, Virtual Method들을 활용한 상속 Class 들의 호출 우선순위

 - override

 - Java와는 다르게 C++, C#에서는 부모 class의 메소드들이 우선순위이고, virtual로 명시해두어야 함

 

2. Singleton Pattern (Static 함수를 활용하여 Component간의 Data 주고 받을 때)

 - Device IO, Manager Script 에 주로 사용 됨

 - onDestroy, Scene 전환 시에도 사용 됨 (전환을 시키는 script는 main camera에 두는 것이 문제 방지에 좋음)

 - Additive Loading이라는 Scene 전환 메소드: 기존의 scene에 새로운 scene을 추가하는 방식

 

3. Strategy Pattern - interface를 사용하여 알고리즘이 서로 교환 가능하도록 하는 패턴

- interface: 기능에 대한 선언 (구현과의 분리), 여러가지 기능을 사용하기 위한 단일 통로

- 같은 기능 다양한 종류를 제작 할 떄 유용

 

4. Simple Factory Pattern

- Factory: 객체 생성을 처리하는  클래스 (Simple factory: 객체 생성 전담 클래스)

    '이러이러한 메소드를 쓸 것이다.' 인터페이스에 선언을 해놓고, 가져다가 반드시 선언된 그대로 모두 구현하면 되는게 인터페이스이고,

    이러이러한 메소드가 있지만 가져다 쓰거나 오버라이드 하거나, abstract가 붙은 메소드는 반드시 구현하면 되는게 abstract class이다.

      (출처: https://marobiana.tistory.com/58 [Take Action])

- Instantiate()함수 : 게임 실행 중에 게임 오브젝트를 생성하는 함수 - Instantiate(GameObject original ,Vector3 position ,Quaternion rotation)

 

5. Factory Method Pattern

- 객체를 만드는 역할을 하는 Method : 예를 들어 어떤 종류의 객체를 몇개 만들어 줄것인지 정의를 해줌 -> 수정할 때 편리

- UseFactoryMethod: API, SDK 함수를 쓰듯이 사용, 함수를 불러서 쓸수있도록 짜여져 있으면 UseFactoryMethod에서 사용하도록 함

- 상황에 따라 수정 적용이 편리하도록 코드 작성

 

6. Abstract Factory Pattern

- Client에 연곤된 객체들의 패밀리를 반환 / 관련성 있는 여러 종류의 객체를 특정 그룹으로 묶어 한번에 일관된 방식으로 생성, 교체

- But, 인구는 인구 끼리 건물은 건물끼리 모으면 종족이 늘어날경우 수정해야할 부분이 많을 수 있다. -> 종족으로 그룹을 추가로 만들어 줌

- 그룹을 어떻게 만들지 결정하는 것도 중요함 듯! -> 최대한 main함수에서는 수정을 안하는 방향으로

- Zerg / Protos / Terran 스타를 만든다고 생각하면 될 듯!

 

7. prototype Pattern (동적 클래스 생성)

- Prototype pattern 은 object 생성에 높은 비용이 드는데 (Prefeb 등) 수 많은 생성 요청을 하는 경우, 또는 비슷한 object를 지속적으로 생성해야 할 때 유용하게 사용

- Marine m = new Marine();  =>  Marine m2 = (Marine)m.Clone(); 한 후에 속성을 변경할 수 있음.

 

8. Flyweight Pattern

- 모든 객체의 데이터 값이 같아서 공유할 수 있는 데이터를 모은다 / 나머지 데이터는 인스턴스 별로 값이 다른 외부 상태에 해당

- 한개의 고유 상태를 다른 객체에 공유하여 메모리 사용량을 줄임 (C++의 Pointer 개념)

- Factory method pattern 이용됨 (이전에 생성한 객체가 있는지 탐색하는 방법이 필요함!!! -> Object pool pattern : Dictionary 자료구조로 구현)

 

9. Object pool Pattern: 재사용 가능한 객체들을 모아 놓은 객체 풀 클래스; 자신이 사용 중인지 여부를 알 수 있는 방법을 제공함 (사용 중, 사용 안 함에 대한 Status 정보 저장 및 반환!), but 여러 곳에서 동시에 재사용하게 하진 않고 한번에 한 곳에서만 사용

 

10. Builder: 복잡한 객체의 단계별 생성에 중점을 두고 있는 패턴 / 부분부분을 먼저 생성 후 마지막 단계에서 생성한 제품을 반환

 

11. State Pattern: !isJumping 같이 현재 진행 중인 상태를 check하는 if문을 작성, but 문제 있음 -> 상태를 별도의 클래스로 캡슐화 하여 각 상태를 클래스를 이용하여 표현함 (ex. 실험의 단계 별 State를 지정해 줄 때)  <중요!!>

- Statemanager를 두고, request() 하는 방식으로 사용

- switch 문으로 하면 깔끔하게 정리됨

-  Action별로 class로 나누어서 변수를 공유하는 것을 최소화하여 유지 보슈에 용이하게 함. https://docs.google.com/document/d/1y_gtycMNrv8yAqhfS1zZU4zArrrc2-O6Wt-aaib65wg/edit

25.StateExB2

 

12. Observer Pattern: 1:N의존성 정의, Subject & Observer Interface로 Subject의 상태를 Observer에 전달

- OnNotify() 메소드로 각 observer에 전달 (foreach 문 응용)

- delegate() Function으로 같은 Patter을 개발할 수 있음. (https://shhyc1001.tistory.com/120)

- NotiHandler _notiHandler;에 Observer들을 등록해주고 쉽게 호출 가능함 / 등록하면 매개변수로 알아서 모두 호출해줌

 

13. Adapter Pattern: 인터페이스 (메소드 이름)가 달라서 코드가 복잡해지는 경우 중간에서 변환해주는 역할을 하는 Pattern / opensource 코드를 가져와서 기존에 있는 환경에서 사용할 때 주로 사용되는 패턴

- 기존 시스템에 비슷한 기능을 하지만 메소드 이름명이 다를 때 유용함, 새로운 부분or 유형이 추가된다면 수정 부분 최소화하여 오류에 대처 빨리 할 수 있음

 

14. Command Pattern: 명령 패턴은 메서드 호출을 실체화, 객체로 감싼 것

- 디커플링으로 코드가 유연 (ex. 입력키변경, 실행취소, 재실행)

- 사용자가 자신만의 입력키를 만들 때 (사용자 정의 키)

- Transform, key 등을 객체로 만들어서 Stack으로 저장

* TIP: 빈 객체를 만들어서 좌표 값으로 설정해 둘 수 있음!!