그러니까 해석하자면, GetComponent가 성능적으로도 좋지 않고 다른 컴퍼넌트를 참조한다는 점에서 컴퍼넌트 패턴과는 맞지 않다고 공부했는데, 막상 유니티 쓰면 쓸수록 GetComponent를 쓸 수 밖에 없는 상황이 생긴다, 다른 컴퍼넌트에 대한 의존성 생김에도 불구하고 결국 이걸 안 쓸 수는 없더라... 라는 얘기를 하고 싶었던 거지?
SR4(succeed4464)2024-11-13 11:25:00
답글
처음 : GetCoponent 는 신인데?
중반 : GetCoponent 는 쓰레기임, 저걸 쓸바엔 캐시화해서 써야함
지금 : 객체지향에서 GetCoponent 나름 쓸만한데?
이 시나리오임
변수로만 안가지고 있다 뿐이지 해당 모듈이 해당 클래스의 이름을 정확히 알고있는데 의존성이 떨어진다 하긴 애매하고, 변수로 안가지고 있으니 스코프를 한정해서 해당 함수나 특정 모듈 소규모로 제한할 수 있다 정도가 맞는 표현일듯
아쥬_POE(duqrlehs)2024-11-13 13:32:00
답글
약간 이런거임. 혼자 작업할 때는 뭘 쓰나 성능상에 문제 없다 싶으면 넘어가고. 협업을 하게 될 경우, 이 모듈을 이 클래스에서 참조하고있습니다. 를 변수나 함수로 레핑을 해두면 남한테 의도를 전달하기 쉬워짐. 반대로 GetComponent()로 감싸서 특정함수 한 두군데에서만 사용하게 구현하면. 이 클래스에서 쓰기는 하는데 님들은 몰라도 됨 ㅋ 하고 의존성이 있다는 사실 자체가 중요하지 않다는 것을 알려줄 수도있음
그러니까 해석하자면, GetComponent가 성능적으로도 좋지 않고 다른 컴퍼넌트를 참조한다는 점에서 컴퍼넌트 패턴과는 맞지 않다고 공부했는데, 막상 유니티 쓰면 쓸수록 GetComponent를 쓸 수 밖에 없는 상황이 생긴다, 다른 컴퍼넌트에 대한 의존성 생김에도 불구하고 결국 이걸 안 쓸 수는 없더라... 라는 얘기를 하고 싶었던 거지?
처음 : GetCoponent 는 신인데? 중반 : GetCoponent 는 쓰레기임, 저걸 쓸바엔 캐시화해서 써야함 지금 : 객체지향에서 GetCoponent 나름 쓸만한데? 이 시나리오임
그런 거였음? 캐싱할 수 없는 경우라면 TryGetComponent를 씁시다
객체지향에서 GetComponent가 의존성을 없앤다고...? void Func( Gameobjct obj ) { var behaviour = obj.GetComponent(); } 같은식으로 쓴다는 얘기인가?
변수로만 안가지고 있다 뿐이지 해당 모듈이 해당 클래스의 이름을 정확히 알고있는데 의존성이 떨어진다 하긴 애매하고, 변수로 안가지고 있으니 스코프를 한정해서 해당 함수나 특정 모듈 소규모로 제한할 수 있다 정도가 맞는 표현일듯
약간 이런거임. 혼자 작업할 때는 뭘 쓰나 성능상에 문제 없다 싶으면 넘어가고. 협업을 하게 될 경우, 이 모듈을 이 클래스에서 참조하고있습니다. 를 변수나 함수로 레핑을 해두면 남한테 의도를 전달하기 쉬워짐. 반대로 GetComponent()로 감싸서 특정함수 한 두군데에서만 사용하게 구현하면. 이 클래스에서 쓰기는 하는데 님들은 몰라도 됨 ㅋ 하고 의존성이 있다는 사실 자체가 중요하지 않다는 것을 알려줄 수도있음
ㄹㅇ 이거 말한거 맞음 이런 느낌을 표현하기가 어렵네