[💬] 님들 delegate, event쓰나용

[익명(211.232)]

프로퍼티는  쓰는편인데 저딴거 쓰면  코드도  보기어려워지던데 ㅠ

- dc official App

[익명(14.52)]

??? 저딴거??? 안쓰는게 문제있음

[익명(211.232)]

ㅇㅇ 루?ㅠ 모르겠어. . . - dc App

[익명(112.158)]

모를땐 그냥 짜. 나도 그랫는데. 사용법 알고나서는 신세계엿다. 델리게이트랑 람다식이랑. 10줄 코드를 1줄로 줄이는만큼의 효과가 잇어. 지금 초보라 모르면 무시해도돼. 하다보면 알게되지 않을까?

[익명(211.232)]

옹킼 - dc App

[익명(223.39)]

코드의질을 다르게 해주는 기능들인데 안쓴다고? 지금 당장 공부해라 모르니까 일단 짜는건 손해다 저건

[익명(110.70)]

없이하다보면 먼가 답답할상황이 오게됨...

[익명(218.153)]

나같은 경우엔 설계를 생각하게 되면서 delegate가 이해가 되었던거 같음. 처음에는 왜 굳이 저런걸 쓰지? 대리자라는 개념을 쓸 필요 없이 그냥 1:1로 갖다 박아버리면 안되나 했었는데, 좀 하다보니까 필요성과 어디에 필요한 지 알게 되었음.

[익명(218.153)]

위에 반응들 보면 그냥 짜라는 사람도 있고 코드의 질 이야기 하는 사람도 있는데, 글쓴게이가 평소 공부를 했을 때 잘 되는 방식으로 하면 됨. 나 같은 경우엔 내가 아무리 생각해도 이해가 안되면 내가 아는 방식으로 벽에 부딪힐때까지 해보고, 한계에 도달했을 때 내 방식으로는 안되는구나를 알고 나서 구조나 설계를 보기 시작했음. 반대로 내가 봤던 학력 높은 프로그래머들은 설계부터 접근해서 이미 근본 쌓고 오는 사람들이 많더라. 커리큘럼 차이인지는 몰라도

[익명(175.223)]

한계에 도달? 이미 다 있는 기술들에 한계가 어딨노?

[익명(211.232)]

델리게이트로 짜면 할 수 있는데 이 메소드를 굳이. . .? 이런생각이라서 아직 유니티 시작한지 얼마안되서 복잡한 로직을 안다뤄서 그럴수도 여튼 ㄱ ㅅ - dc App

[익명(218.153)]

175.223 // 기술적 한계를 말하려는게 아니었음. 지금 내가 아는 좁은 지식으로만 계속 짜다가는 나중에 감당이 안되겠구나를 나는 느꼈었고, 그 때 지식 영역을 넓혀야겠다 생각이 들었음. 설계에 관한것도 그때마다 찾아봄

[인디갤용아이디(dlselrofdyddkdlel)]

이벤트 개념이 필요할때마다 아주 잘 쓰는 유용한거임

[익명(211.232)]

ㅇㅋㄷㅋ - dc App

[reveneer(125.137)]

매우 많이 씀. ui 컨트롤할때는 100% 쓰고 레이어링 해서 논리단과 구현단 데이터단 통신할때도 씀. 이벤트를 써서 의존성을 끊을 수 있음.

[익명(58.120)]

1. Ui에 존나 들어감. 2. 필요한 클래스를 전부 레퍼런스 잡아두는 코드는 안좋다라는게 의견임. 이렇게 만들면 서로 엉켜서 스파게티처럼 되고 서로 참조를 하는 상태를 커플링 이라함. 델리개념은 디커플링 에 중요한 솔루션임 Ui해보면 딱 한번 혹은 딱하나 만 필요한 참조가 존나 많아져 이런걸 변수 선언하고 Set해주다보면 클래스가 진짜 개판남

[익명(211.204)]

내 코드 50%이상이 액션하고 이벤트임

[익명(122.43)]

무조껀 씀

[raveneer(121.150)]

근데 이벤트 남용하면 의존성이 모호해져서 헷갈릴때도 생기는 거 같음. 여러놈들이 += 로 달라붙을 수도 있는데다가... 적당한 커플링은 필요하지 않을까?