Scriptable Object 개요

아키텍처의 지향은 스크립터블 오브젝트이다(유니티에서). 뭔소리인가??

 -> 좋은 아키텍처란 모듈화에서 온다. 기능을 잘게 세분화하는 게 중요한데, MonoBehav는 최소한의 프로퍼티를 명시하고, 참조하는 시점과 조건의 틀만 정의한다. 즉 틀에 프로퍼티를 넣는 역할만 한다.

프로퍼티가 기능을 정의하려면 Mono로 만든 system, 컴포넌트, 스크립터블 오브젝트가 필요하다. 여기서 아키텍처는 SO를 선호한단 소리다.

이점이 뭘까 - mono만 작성해주면 되는 데 프로퍼티에 대한 SO를 따로 만들면 귀찮을 수도 있다. 하지만, 초기화 작업, 수정 작업은 인스펙터 창에서 가능하고, 확장 작업은 신규가 아닌 기존 소스재사용과 에셋생성으로 한다. 모두에게 언제든지 참조 가능한 인스턴스이므로 유연하다.

 

모듈화/ 확장성/ 쉬운 디버깅/ 테스트/ 밸런싱/ 간결한 코드

1. 씬전환이 수월하다.

씬을 비울수 있다. 씬이 채워지는데에는 디펜던시(프로퍼티의 일종, 외부클래스라 생각하자)를 참조 하기 위해서인스턴스 배치 혹은 그를 위한 싱글톤매니저를 배치하기 때문인데, SO는 어디서든 참조가 가능하기 때문에 싱글턴 매니저 같은 것을 씬에 띄워 놓을 필요가 없다. 매니저의 초기화 작업 또한, 필요가 없다.

 

2. 모든 오브젝트를 프리팹화

스크립트에 드래그 앤 드랍 하던것(disk에 저장이 안되기 때문에 씬에 배치하여 Scene.meta파일에 저장)을 SO는 객체에 기능추가 또는 제거 할때 프리팹단에서 컴포넌트만 반영해 주면 된다. (.Asset은 disk에 저장이 되므로 프리팹단에서 추가, 제가만 해주면 된다).

 

3.디버깅이 쉬워진다. Asset의 inspector에서 값이 점검 가능하다. 옵저버 패턴의 이벤트 리스너와 DataSet을 통해 각개체의 리스너와 Dataset을 inspector에서 확인 가능하다.

 

4. enum대체가능 하다. enum의 단점은 중간요소제거나 순서 변경이 발생하면 재정렬이 필요한데, 이런 단점이 없어진다.

 

5. 플레이가 종료되어도 값이 유지 되므로 테스트 밸러싱에 유요하다.

 

6. inspector로 값을 보거나 SO코드만 보면 된다. Mono는 프로퍼티 참조시점과 조건만 정의한다. 

새로운 기능이 추가 될때, SO랑 Asset만 추가하면 된다. -> strategy pattern을 사용?? 기능의 정의 추가가 아니라 새로운 기능(인터페이스 같은 것)이라고 생각하면 편할 듯 하다.