[🐣질문] 유니티 모든 변수를 public으로 선언해도 괜찮음?

[익명(112.153)]

유니티 코딩 중

기왕 변수 선언 할 거

전부 public으로 선언 하고 있는데

문제가 생기진 않겠죠?

[ㅇㅇ 1(1.238)]

왜 이러시는 건데요 - dc App

[ㅇㅇ 2(1.230)]

유튜브같은데에 SOLID 맛보기로라도 보고 코딩하셈

[퍅셔미(wvvwvwwvw)]

방바닥에 압정 쏟아놔도 안밟는다는 가정하에 사는데 문제는 없죠

[글쓴 ㅇㅇ(112.153)]

엥? ㄹㅇ 문제 잇노?

[ㅇㅇ 11(125.242)]

접근하면 안되니까 private으로 선언하는건데 편하자고 pulic으로 선언하고 이곳저곳에서 다접근해놓고 나중에 문제생기면 해결하기 힘들지

[ㅇㅇ 11(125.242)]

문제가 없으면 언어만든애가 private을 왜만들었겠음..

[마치쨩(machichan)]

너가 짠 코드 너가 가물가물해질쯤에 문제가 생김

[ㅇㅇ 3(222.236)]

솔직히 위에 댓글 호들갑이라고 생각함

[ㅇㅇ 3(222.236)]

뭐 간단한 공부 규모일거고 아직 익숙하지 않아서 일단 퍼블릭으로 하는데 뭔 문제가 생기겠음 문제 생길 규모였으면 진작 구분해서 썼겠지

[글쓴 ㅇㅇ(112.153)]

아니 근데 ㄹㅇ 어떤 문제가 아니 근데 ㄹㅇ 어떤 문제가 있음? gpt한테 물어봐도 납득이 안되네

[ㅇㅇ 4(1.230)]

일단 구현이 먼저니까 전부 퍼블릭으로 해도 괜찮음 나중에 고치면 되니까 구현에 집중하셈

[익명(toomany99)]

문제라는게 퍼블릭때매 없던 버그가 생기는 게 아니라 너가 스크립트 쌓다보면 서로 참조하고 수정하고 할 일이 생길텐데 그 때 옛날에 짠 코드 보면 본인을 줘패고싶을거다 이말임

[익명(59.8)]

어차피 처음엔 모른다 왜 그렇게 public private나눠놨는지 그래도 궁금하면 객체지향 캡슐화 찾아보고 좀 코드량이 많아지면 깨닳게 됨 왜 그렇게 유지보수 노래를 부르는지

[글쓴 ㅇㅇ(112.153)]

깨닳게 -> 깨닫게

[익명(121.185)]

객체 지향이 발전하게 된 게 협업을 효율적으로 하려고 생긴건데 혼자 하는거면 상관없음 변수명 한글로 지어도 상관없고 int a,bc이런식으로 님만 알아보게 해도 됨근데 혼자서 프로그램 작성해보면 알겠지만 과거의 나는 타인임이 새끼는 무슨 생각으로 이런 코드를 짰을까...? 하게 되는 일이 하루 이틀이 아닐거란 말이지... 접근 제한자로 막는 이유는 내가 작성한 클래스의 동작을 외부에서 의도하지 않게 바꾸는 것을 막으려는 것임이걸 맘대로 허용하면 결국 이곳 저곳에서 내 변수를 맘대로 바꾸게 되고이걸 이쪽저쪽에서 꼬여버려서 스파게티를 만들어버림코드 작성에서 생각보다 우선순위가 매우 높은게 코드의 가독성인데 이 가독성이 10창나면 이상한 실수로 버그를 만들어버림

[글쓴 ㅇㅇ(112.153)]

감사합니다..

[ㅇㅇ 5(121.159)]

코드량이 무지막지하게 늘어난 이후에도 모든 변수가 퍼블릭이면 이제 너가 그 변수명을 다 외우고 있어야 문제가 안 생김

[ㅇㅇ 6(211.54)]

public private정도는 인스펙터가 거추장스러워서라도 알아서 구별하는데 시리얼라이즈는 리얼 필요없다고 생각. 유니티 공식사이트에서 성능도 더 안좋다했음

[211214(tomatoss)]

시리얼라이즈필드는 나같은 초보에게 유용하다 생각함. 아무데서나 접근할 수 없게 꽁꽁 싸매놔야 전역 접근 유혹을 떨칠 수 있음 필연적으로 프로퍼티를 많이 쓰게 될텐데 예외처리도 쉽고 디버깅도 쉬워지고 AI한테 물어볼 때도 잘 알아먹음

[ㅇㅇ 7(211.210)]

이거 안된다고 하는놈들은 싹다 허수임 ㄱㅊ

[ㅇㅇ 7(211.210)]

대충 인디레벨은 변수명 이쁘게만들기 = 접근자 제한 이정도임

[익명(1.237)]

결과물 자체는 객체지향 빡세게해서 만든거랑 차이없음. 그런데 퍼블릭으로 여기서 참조하고 저기서 참조하고 오만곳에서 다 참조하면 나중에 버그 생겼을 때 원인 찾기 어려움. 본인이 만든 코드도 원인 찾기 어려운데 협업할 때 다른 사람이 이런 코드 보면 눈 돌아감

[ㅇㅇ 8(61.85)]

나중에 상속 2~3번 되면 ㅈㄴ 귀찮아짐. 그거 빼면 팀업 아닐경우 아무 상관 없음

[익명(rent1081)]

미로와 같은 코드 가독성의 문제가 생김 근데 뭐 캐주얼 같은 게임 만들거고 빨리 만들어버리는 용도면 해도 되는데 대신 이거 습관 들리면 좀 안 좋으니까 애초부터 안 하는 걸 추천 - dc App

[ㅇㅇ 9(222.236)]

public의 문제점은 적는게 귀찮음

[토끼주문(icyselec)]

? 딱히 문제는 없는데

[ㅇㅇ 10(118.45)]

하셈 ㅇ

[ㅇㅇ 12(211.226)]

혼자한다고해도 과거의 나와 협업임 ㅋㅋㅋ 3달전에 쓴코드 막힘없이 쭉쭉 읽히면 올 퍼블릭해도 상관없음

[ㅇㅇ 13(14.32)]

솔직히 혼자 만들면 상관없지

[ㅇㅇ 1(1.238)]

니 코드를 보고 다른 코드몽키(미래의 너도 포함)가 뭔 개지랄을 할지 모르니 이상한짓 못하게 막아버리는 거임 ㅇㅇ

[익명(fujiwara1)]

1인개발만 하셈 ㅇㅇ

[211214(tomatoss)]

저러면 없던 문제도 생긴다 생각함.. 본인이 안 헷갈릴려고 일방통행만 되도록 닫힌 구조로 만드는 건데 모든 클래스가 전역적으로 접근이 가능하게 되면 교통정리가 아예 안 됨 초기화 순서도 꼬일 수 있고, 순환 참조도 일어날 수 있고, 부모가 자식 메서드를 갖다 쓰고.. 뭐 하나 코드 수정할려면 다 얽혀 있어서 유지보수가 전혀 안 될 거임. 갈아 엎는게 빨라지는 순간이 옴 물론 퍼블릭 쓰면서도 스파게티, 거미줄 구조로 안 만들 수는 있겠지만 굳이 편한 길을 두고.. 그럴 이유가 없음