[💬] 님덜 Object.Find 안쓰려고 Public 으로 드래그하는데괜찮나여

[하쿠나(220.116)]

Find로 하는거는 내 하이어라키를 전부다 체크해서 안좋다고해서

public으로 드래그해서 쓰는데 괜찮나요??

예를들어서

private Text CoinText;

하고 Start문에서

CoinText = GameObject.Find("CoinText").GetComponent();

이렇게 안하고

public Text CoinText;

한뒤에 하이어라키에 그텍스트 드래그해서 넣어서 쓰고있는데

이러면 GetComponent() 이것도 안해도 되더라고요

근데 이렇게하는게 더 안좋은거면 차라리 GameObject.Find 해야겠다고 싶은데

어떤게 더 나은건가요???

[익명(125.191)]

ㅇㅇ 드래그 해서 쓰라고 유니티가 있는거야

[익명(61.82)]

인스팩터에 드래그앤 드롭 되게 해준 이유지

[하쿠나(220.116)]

하핫! 괜찮은거맞죠!? ㄳㄳ 아니 근데 public을 너무 많이해서 너무 많은걸 드래그하다보니 이게 맞나 싶어서 한번 글올려봤어용

[Duque(duque)]

https://docs.unity3d.com/kr/530/ScriptReference/SerializeField.html

[익명(112.154)]

유니티에서도 그렇게하라하긴 했음

[Duque(duque)]

파인드는 없는거다 생각하고 쓰지마라

[하쿠나(220.116)]

네넵!!

[모노모노모노(monosw2000)]

Find는 가급적 쓰지 않는게 좋습니다. 개발자는, 특히 소수로 돌아가는 팀에서의 개발자는 대부분의 상황을 통제하거나 예측할 수가 있습니다. 그러면 가급적 Find보다는 미리 드래그해서 캐싱해주는게 성능상으로도 좋지만, 무엇보다 좋은건 'Find해서 못 찾으면 어쩌지?' 같은 ㅈ 같은 의문이 떠오르지 않는다는 사실입니다. Find를 하면 없을 수도 있고, 그럴 경우에 추가적인 조치가 필요해 집니다. 그러면 자연스레 코드도 복잡해지고, 성능상으로도 문제가 되겠죠. 그러니 미리미리 에디터에서 드래그를 통해 캐싱을 해두는게 생산성 측면에서도, 성능 측면에서도 좋습니다.

[모노모노모노(monosw2000)]

그리고 Find를 쓰는 상황이라면 대부분, 아예 완전히 다른 상황에 코드가 뚝 떨어지는 경우입니다. 대표적으로 에셋 번들로 다른 프로젝트에 떨어진 경우죠. 이런 경우면 번들을 만드는 상황에서 해당 프로젝트의 환경을 체크할 수가 없지요. 대부분의 경우 원하는 오브젝트가 없으니 만드는 쪽이겠지만 반대로 2번 로드되는 경우, 이미 만들어져 있는데도 생성하게 되는 뻘짓을 하게될 수 있습니다. 이런 경우가 아니라면 대부분 인스턴스가 되서 무언가를 찾을 경우 싱글톤 매너저 클래스를 통해서 찾는걸 권장합니다. 매니저 클래스는 개발자가 더 쉽게 상황을 통제할 수가 있고, 거기서 데이터를 IO해주면 누구에게 무엇이 있는지 파악하기도 쉬워지구요.

[익명(117.111)]

몇몇 개발환경에선 드래그 정보 사라지더라 ar개발중인데 이거때메 골치아픔

[산적대왕(raveneer)]

zenject 함 써보쉴? (약팔이 등장)

[익명(175.113)]

그게 제일 좋은 방법이야. - dc App