보통 의존성 주입은 FindObjectofType를 쓰는데

이는 씬에서 검색을 하기때문에 많은 자원을 먹는데

GPT가 추천을 하지 않음

싱글톤은 그에반해서 분명히 성능적 이점이 존재함

보통 FindObjectofType를 쓸때 의존성 컨테이너, 즉 스타트업 스크립트를 작성해서 의존성 컨테이너를 만들고 그걸 바탕으로 의존성을 주입하는게

전통적 방법이고, 많은 패턴 책에서 장려함

다만 이러한 의존성 주입이 커질수록 결정적으로 코드가 복잡해지기때문에 작업속도와 생산성이 떨어질 수 밖에 없음.

유니티에서는 zenject와 같은 프레임워크를 지원하는데,

이 경우 클래스에서 인터페이스-구현클래스 생성-의존성 주입 컨테이너로 해야해서 이 경우 내 인벤토리 시스템을 다시 고쳐야함.

장단기적으로 따지자면

public interface IItemDatabase

{

}

등으로 만들고,

var itemDatabase=new ItemDatabase();

Field Item 생성시 아이템 데이터 베이스의 인스턴스 주입이 맞는데,

이게 맞는건가 싶다.

일단 싱글톤의 장점

1. 쉽고 빠른 구현

2. 성능상의 분명한 이점

3. 참고할 수 있는 많은 레퍼런스.

싱글톤의 단점

1. QA가 어렵고 버그테스트가 어려움

2. 모듈화로 들어갈 경우 모듈화 싱글톤의 개념이 훨씬 어려움

3. 추가 기능 구현에 따른 어려움.(폐쇄성)

의존성 주입을 사용할 경우 장점

1. 낮은 결합도로 인한 코드 재사용성 증가

2. 버그 테스트가 쉬움.

의존성 주입의 단점

1. 내 수준에서 쉽지 않은 코드 구현

2. 확장성있는 코드

나의 경우 이미 게임 매니저 클래스를 싱글톤으로 구현했기때문에 싱글톤이 많을수록 점점 더 버그 테스트가 힘들어진다.

이 경우 절대적으로 내가 팔아먹을 상품인 게임에서 유저들에게 불쾌한 경험을 줄 버그를 장기적으로 수정하기가 힘들다.

따라서 원래라면 의존성 주입을 선택해서 스타트업 스크립트로 의존성 컨테이너를 작성 하는게 맞다.

하지만 나의 경우

1.Zenject 프레임워크의 사용 경험 없음

2.완성된 인벤토리 시스템의 폐기

이 2개를 고려해야하는데, 이는 상당히 선택적으로 많은 문제를 따른다.

다만 완성될 경우엔

1. QA상의 이점

2. 완성된 인벤토리 시스템에 시스템 추가구현상의 이점

이중 2번이 상당히 매력적인 옵션인데, 잘 모르겠다.

전업 개발자라면 배움의 시간이 충분하지만 나는 노가다 공장일을 하면서 게임 만들기떄문에 빠듯한데

어렵다. 인생

완성한걸 부순다는 심리적 저항감이 너무 크다.

벌써 몇번을 했지만 이게 제일 힘들다

시간이라는 리소스가 조금만 더 많았으면 좋았을텐데

배움의 나이가 너무 늦었고, 시간이라는 리소스가 너무 부족하다.