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
State.cs ConcreteStateStand.cs ConcreteStateJump.cs ConcreteStateDown.cs ConcreteStateAttack.cs ConcreteStateSkill.cs MyAction8.cs
docs.google.com
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: 빈 객체를 만들어서 좌표 값으로 설정해 둘 수 있음!!
'Programming > Programming Skills' 카테고리의 다른 글
| Git / Github 명령어 (0) | 2022.07.17 |
|---|
