[💬] 3년 웹&유니티 개발자 시선에서 쓰는 의존성

[익명(account8878)]

옛날엔 싱글톤을 쓰면 안되니깐 유니티도 스프링 처럼

di넣을려고 별 짓 다했는데

애초에 두 프레임워크가 추구하는 의존주입 방식이 다름

스프링은 di 자체가 매우 편한데 사실상 이것도 내부 소스 까보면 싱글톤 패턴이고

그럼 유니티에서 추구하는 의존성 주입은 그냥 인스펙터에

넣는 방식을 추천하는데 동적으로 생성되는 것에 있어

이 방법은 안먹힘

또 컴포넌트 패턴이 주다 보니 애초에 같은 객체 내의 컴포넌트 접근은 GetComponent로 접근이 가능함

즉 정리하자면

같은 프리팹 또는 씬에 배치된 것은 인스펙터에 박고

동적 생성을 하는데 같은 객체안에 있다하면 GetComponet로 받고

동적생성도 하고 같은 프리팹에도 없다 하면

싱글톤 써주고 있음

또 데이터 부분 예를들어 돈이나, 유저의 체력 부분을

참조해야하면 이걸 싱글톤으로 빼도 되긴하는데

참조하는 대상이 많으면 그냥 리스너 달고 sub-pub 형태로 구현하는 편임

물론 3년 동안 웹에서 구르고 독학으로만 유니티 했다보니 정답이 아닐 수 있으니 더 좋은 방법있으면 댓글 부탁함

- dc official App

[ㅆㅇㅆ(124.216)]

의존성으로 만들다보면 의존성 주입하는 객체들끼리 참조 순서 안맞추면 순환참조 자주 일어나는데 이거 어케 해결하냐 난 이게 젤 문제같은데

[익명(account8878)]

순환참조 문제는 순환참조되는 객체끼리 묶는 하나의 클래스를 따로 만드는걸 추천함 그래서 해당 클래스에서 먼저 참조되는 두 클래스를 생성하고 순환참조되는 클래스는 직접적으로 그 클래스를 갖다 안쓰면 댐 예를들어 a와b가 순환참조 이슈가 발생하면 c클래스 만들어서 a에서 b를 부를 때 c를 참조하고 부르는거지 - dc App

[ㅆㅇㅆ(124.216)]

나 이거때문에 지금 2주 날렸는데 어느정도 감이 왔다. 고맙다

[익명(account8878)]

https://siyoon210.tistory.com/170
요글도
확인해보면 좋아 핵심은 A->C<-B
형태면 쉽게 끊을 수 있어 ㅇㅇ - dc App

[ㅆㅇㅆ(124.216)]

와 진짜 너무 고맙다. ㅜㅠㅠㅠㅠ

[ㅇㅇ 1(124.54)]

코드재사용을 위해선 결국 순환 생성이 계속 필요하게 됨 근본적인 해결방법으론 글쓴이가 말한 방식대로 동작하기 위해서 프로젝트의 의존성으로 주입되는 모든 객체를 Proxy 패턴으로 제공하는 것이 가장 단순함 성능 문제도 있고 기계적인 작업이 좀 필요한 편 사실 DI 프레임워크를 굳이 쓰는 이유는 이 기능을 가져다 쓰려는 목적이 더 큼

[ㅇㅇ 1(124.54)]

GameObject 를 조립하는 과정에 있어서 노출될 필요가 있는 객체가 아니면 굳이 Inspector 로 노출하지 않고 Singleton 사용하는 편 다만 Scene level 로 Scope 를 제공할 필요는 있으니까 Scene 별로 Scope binding 을 두고 의존성 관리에 포함되는 Game object 들이 뒷단에서 생성/삭제 시 의존성을 추가/제거 할 수 있도록 class layer 를 하나 더 두는 편

[ㅇㅇ 1(124.54)]

단방향으로 데이터가 순회하는 것이 좋기 때문에 결국 의존성관리에서 도움을 받아 Game logic 은 중간다리에 use case 로 전부 배치하고 실제 물리 시뮬레이션이나 UI, FX 같은 게임적 Presentation 요소만 Component level 로 관리하는 편 이 때 게임 규칙에 따라 use case 에서 위 시뮬레이션에 해당하는 (속도, 좌표) 등의 정보가 필요 할 수 있어 그런 정보들만 샘플링으로 Repository layer 에 동기화시키는 편 이러면 Unity 의 Presentation layer 는 독자적으로 놀 수 있고 Game client 내 domain, infrastructure layer 는 그냥 C# Project 처럼 굴러가서 좋음

[ㅇㅇ 1(124.54)]

이걸 Client backend 라고 설명하는데 (이름이 좀 웃김 ㅋㅋ) Unit test coverage 는 Client backend 에 한정해서만 신경써도 되서 좋음. Test 도 정말 쉬워짐. 내가 말한대로 동작하기 위해선 작성해야하는 코드가 좀 있어서 DI 쪽으로 오픈소스인 RefleX 랑 RX 쪽으로 오픈소스인 UniRX 를 쓰고 있음

[ㅇㅇ 1(124.54)]

나같은 경우 앱이라서 웹이랑은 개발환경이 좀 달라서 용어라던가 그런게 좀 모호 할 수 있는데 Data layer 外 상태를 stateless 하게 무시하는 개발환경에서는 이렇게 개발하는게 훨씬 "덜" 신경쓰일거임 솔직히 실제 개발에는 큰 차이는 읎다고 생각함 애초에 인디게임 개발환경상 본인이 script asset을 매우 공격적으로 투입하지 않는 이상 Project 가 복잡해질 가능성 자체가 매우 낮음.. 설계에서 지나치게 복잡하게 나왔다면.. 이게맞나 다시 고민해볼 필요도 있다고 생각하고