[💬] 너네 유니티에서 클래스 멤버변수로

[익명(223.39)]

monobehavior를 상속받는 클래스들

들고 있지마라 물론 들고있어도 상관없긴한데

컴포넌트패턴의 최강의 테크닉을 이러면 못쓰게돼

바로 부품을 갈아끼우는 기술

니네가 Player클래스나 Enemy클래스를 만들었다 치자

Player가 enemy가 되고 싶으면 어떻게 처리하냐?

아마 컴포넌트 자체를 갈아끼우는게 가장 깔끔한 방법일거야

근데 이런처리를 하려면 컴포넌트가 다른 컴포넌트에 종속되어

있으면 안돼

(아물론 컴포넌트를 갈아끼우지 않아도 되는 컴포넌트들은

해당사항 없어)

쨋든 이왕이면 다른 컴포넌트를 멤버변수로 들고있기 보단

그 컴포넌트의 몸통인 게임오브젝트를 들고있자

[익명(118.235)]

흠.. 그게 맞다고 생각함?

[익명(175.119)]

난 그냥 Entity에서 Player나 Enemy로 파생해서씀

[익명(223.39)]

그러면 분기만 잡아야하잖아

[익명(223.39)]

분기문

[ㅇㅇㅇ(106.102)]

어렵군.. 예를들면 트랜스폼/콜라이더 등을 들고있지말고 게임오브젝트를 들고있다가 겟컴포넌트해서 쓰라는 말?

[익명(223.39)]

ㄴㄴ 그 용도를 파악해봐 트랜스폼이나 콜라이더를 겜도중에 갈아끼울일이 있어? 없잖아 그럼 필요없어 종속되어도 상관없음

[익명(119.194)]

ㅋㅋ 그럼 넌 GameObject들고 update 에서 계속 GetComponent호출하셈 나는 Player, Enemy부모로 Unit이라는 클래스 만들어서 갈아끼울테니까

[익명(223.39)]

update에서 계속 겟컴포넌트 할 필요없고 겟컴포넌트 자체도 딕셔너리에서 꺼내오는거라 검색속도 엄청빨라 ㅇㅇ 그리고 니가 말한 구조가 ㅂㅅ같아서 내가 생각한 방법이야 넌 그걸 위해서 enum이든 태그든 해당 클래스를 식별하기위한 변수를 한번더 정의해야하잖아

[익명(119.194)]

컴포넌트 자체를 캐싱안하는데 update에서 GetComponent 호출은 안한다고 어떻게? GetComponent한번 호출할때마다 GC Allocation 발생하는건 알고있음? 한개의 Player를 위해 수백개의 Enemy Update문에서 GetComponent하는건 딱히 좋은 습관은 아닌거 같은데? 그리고 다형성이용해서 설계하는데 설계가 잘못된거 아니고서야 enum으로 클래스 식별을 왜함

[익명(223.39)]

내 글하고 딴 얘기하는것 같은데? 겟컴포넌트를 호출안하고 부모로 캐스팅해서 접근하자는 것같은데 내가 말한 문제는 컴포넌트클래스끼리 서로 종속되어 있다면 컴포넌트를 붙혔다 땠다 하는거 자체가 심각한 오류라는 뜻임 니가 Unit을 다른 클래스에서 들고있을때를 말하는거야 글고 GetComponenet로 왜 업데이트에서 계속 체크를 해야하냐고 ㅋ 해당이벤트가 발

[익명(119.194)]

다른함수에서 사용안할꺼면 다른 오브젝트의 GameObject자체를 들고 있을 필요가 없지 GameObject를 맴버로 들고있다는건 다른 함수에서도 사용할껄 상정해야 하는데 자기 코딩하는 경우만 생각하는건가? 난 니가 어떻게 코딩했는지 안봐서 몰루겠다

[익명(119.194)]

분기문 만들기 싫어서 한다는데 설계 잘하면 분기문 쓸 일 자체가 많이 없고, 혹시 쓴다해도 형변환후에 null체크만 하면되기 때문에 변수나 enum자체를 안씀

[익명(122.39)]

Dependency Injection을 공부하시는게 어떰?

[익명(223.39)]

매니저 하나 따로파서 던지는 형식이 의존성을 해결해주긴 하지만 그것까지 설명하면 길어져서...