[💬] oop문서 보는데 public보다 get set으로 참조하라는데

[ㅆㅇㅆ(112.109)]

public만 쓰는게 최적화는 더 빠른거 맞지?

멀티플레이 게임 아닌이상 그냥 public써서 다른 곳에서 접근하는게 더 편하고 그렇게 해도 의미없지?

어차피 인디 게임이니까.

근데 누군가가 게터, 세터 버릇 들여놔야 한다고 무조건 인디 개발 규모에서도 게터 세터 연습하라던데

맞냐

[거붓(ggp02217)]

프로퍼티를 왜 쓰는건지 공부하자

[거붓(ggp02217)]

https://constructionsite.tistory.com/38

[ㅆㅇㅆ(112.109)]

근데, 값을 넣을때 처리할 게 없다면 굳이 게터 세터 쓸 필요가 없지 않나? 근데 왜 남의 코드보는데 굳이 public만 써도 되는걸 강박적이게 게터 세터 해대는거지

[거붓(ggp02217)]

이름도 실력도 작품도 모르는 그 누군가에게 꼭 믿을 필요가 있냐

[ㅆㅇㅆ(112.109)]

레딧보고 있었음

[익명(124.111)]

게터세터를 만들어놓아야 read 랑 write 하는 부분이 구분이되는데 퍼블릭으로 풀어놓으면 그게 힘들잖아

[ㅆㅇㅆ(112.109)]

흠

[익명(124.111)]

그리고 만약에 a라는 데이터는 내부에서 write하고 외부에선 read만 하는경우면 private으로 막고 게터만 만들어 놓으면 그 데이터가 내부에서 값 세팅하고 외부에선 읽기만 하는 구나라고 구별할 수 있지

[익명(124.111)]

이게 이해가 안되면 그냥 마음대로 코드작성하고 한달뒤에 다시 봐봐

[ㅆㅇㅆ(112.109)]

근데 외부에서 값 수정할거면 세터 쓰잖아? 근데 굳이 세터 안써도 흠... 일단 알겠음 다시 공부해볼게. 이 개념 알고 있다 생각했는데 아직도 헷갈리네

[익명(124.111)]

ㅇㅇ 외부에서 값수정할거면 세터를 쓰라고 ㅋㅋ

[익명(124.111)]

그냥 간단하게 데이터에 마우스오른쪽 클릭하고 모든참조 찾기했을 때 데이터넣는곳이랑 가져다 쓰는곳 다보이는곳이 보기편하냐 아니면 게터 세터 구별해서 볼때가 편하냐

[익명(222.106)]

혼자 프로젝트 관리할거면 go to를 쓰던 노상관

[익명(118.235)]

머리로 이해 안되면 몸으로 깨져봐야지 작업환경상 필요 아예 없으면 해도 되고

[익명(118.235)]

혼자할거면 뭐 상관 없음

[익명(118.39)]

진지하게 최적화는 아예 생각하지 말든가 아니면 제대로 공부해라 최적화가 왜나와 거기서

[ㅆㅇㅆ(112.109)]

아니, 당연히 이론으론 알지. 게터 세터 왜 쓰는진 알고, 정보은닉때문에. 근데 굳이 public으로 쓰면되는거 getter,setter로 까지 바꾸던게 대부분인데 대체 왜 그런가 싶어서 하는 말임

[익명(124.111)]

너가 그 대상을 컴퓨터로 잡아서 최적화 이런쪽으로 생각하는것같은데 대상을 사람으로 잡고 사람이 개발하기 편하려면 어떻게 해야할까 생각하면 왜쓰는지 답나옴

[ㅆㅇㅆ(112.109)]

그렇군 뭔 뜻인지 알겠다

[익명(soulcoin1)]

컴파일러가 최적화해주는 부분 + 설령 컴파일러가 최적화를 안 해준다고 해도 80/20 법칙에 따라 무의미한 짓임

[익명(soulcoin1)]

거기에 더해 get/set 을 통해 객체의 property 를 '표현'함

[익명(soulcoin1)]

객체의 멤버 변수와 property 는 엄연히 다른 개념임 property 를 왜 쓰는지 모르겠으면 oop 를 좀 더 공부해보셈

[익명(usnned)]

인터페이스는 Field를 가질 수 없지만 Property는 가질 수 있음

[ㅆㅇㅆ(112.109)]

이 개념은 모르겠네

[익명(124.111)]

interface는 필드 (멤버변수)는 가질 수 없지만 프로퍼티는 가질수 있다는 이야기야

[ㅆㅇㅆ(112.109)]

그렇구만

[익명(118.130)]

인디게임에서 너무 따지면 힘든데 게임 재미있고 돌아가면 그만임

[익명(220.80)]

코드가 중구난방 개똥같이 되어봐야 정신차리지ㅋㅋ 몇줄 안짜본거 티난다...

[ㅆㅇㅆ(112.109)]

ㅠㅠ

[익명(110.47)]

사람들이 프로퍼티를 처음 접할 때 크게 착각하는 것 중 하나가 프로퍼티를 필드랑 동일한 개념으로 생각한다는거임. 그래서 이런 질문이 나오는거고. 프로퍼티는 메서드임. 따라서 필드와 완전히 다른 개념임. 다만 getter와 setter를 메서드가 아닌 필드를 다루듯이 사용하고 싶어 프로퍼티 개념이 있는거임.

[익명(110.47)]

프로퍼티는 메서드이기 때문에 이것을 참조하는 외부 클래스에 신뢰성을 보장해줌. 데이터를 get set하는 과정을 안전하게 처리해준다는 신뢰성을 보장하는거임. 가장 간단한 예시는 Health에 get set을 할 때 내부 로직에서 0 ~ MaxHealth 사이에서만 값이 set 되도록 clipping하는 경우를 들 수 있음.

[익명(110.47)]

필드는 데이터 그자체이기 때문에 값을 주고받는 과정에서 당연히 어떤 사용자 로직도 처리되지 않음. 그렇기 때문에 신뢰성과 안정성이 떨어지고 OOP에서는 이를 지양하는거임.

[익명(110.47)]

다만 사람들이 특히 헷갈려하는 지점이 너가 물어보는것과 같이 필드 대신 자동구현프로퍼티 사용인데 이게 왜 필요한지 의문일 수 있음. 이것은 외부 클래스에 신뢰성을 보장하는 측면, 나중에 유지 보수를 용이하게 하기 위한 관리 측면에서 필요한거임.

[익명(110.47)]

너가 처음에 Health 프로퍼티를 선언할때는 별다른 기능이 필요없을거 같아 자동구현 프로퍼티로 선언했지만 나중에 clipping이 필요하단걸 깨닫고 수정해야할 수 있음. 이 때 외부 클래스에서 프로퍼티로 참조하고 있었다면 Health 프로퍼티의 내부 로직만 수정하면 됨.

[익명(110.47)]

그런데 필드로 참조하고 있었다고 생각해보셈. 너가 새롭게 내부 로직이 구현된 Health 프로퍼티를 만들어야하고 그거에 맞춰서 기존 필드를 참조하고 있던 모든 클래스를 필드참조에서 프로퍼티 참조로 전부 수정해야함.

[익명(110.47)]

또한 프로퍼티를 사용하면 확장성이 용이함. 처음에 Health를 자동구형 프로퍼티로 선언했다가 clipping이 필요할거 같아서 내부 로직을 추가해고, 체력이 변할 때 체력 게이지 UI를 변경해야할거 같아 직접 UI변경 로직을 넣거나 OnHealthChanged와 같은 이벤트를 발동시켜 외부 클래스에서 등록시켜 사용시킬 수 있음. 필드는 이 모든게 안됨.

[익명(110.47)]

또한 위에서 얘기한대로 프로퍼티는 인퍼페이스 멤버로 가질 수 있음. 그 이유는 맨처음에 얘기한 메서드이기 때문임. 즉, 프로퍼티는 추상화가 가능하다는 것임. 그렇기 때문에 확장성은 더더욱 늘어남.

[익명(110.47)]

이정도로 자세히 설명했으면 이해하셈. 못하겠으면 접는게 더 빠름.

[익명(124.111)]

글 잘써놨네

[ㅆㅇㅆ(112.109)]

완전히 이해했다. 고맙다

[ㅆㅇㅆ(112.109)]

객체의 속성=프로퍼티, 객체의 실체가 담기는 곳=필드라는 개념이네. 이런 느낌인거네 이해했음 고맙다. 이제 감잡힘