자바가 C++에서 객체랑 구조체를 언어적으로 분리안하고 쓰던거 그대로 따라해서 생긴문제라고 봄. 나는 외연적으로 봤을때 객체라는 개념에 멤버변수가 필요하다고 생각 안함.
그리고 게터 세터 쓰느라 빡치는건 그냥 문법이 장황해서 그런건데, 이미 있는 언어에서 그걸 근본적으로 고칠수는 없으니 프로퍼티니 어노테이션이니 해서 땜빵하는거지.
게터 세터는 워낙 단순해서 그게 부각되어 보이는건데, 다른곳에서도 똑같은 오버헤드를 겪으면서도 인지하지 못하는거라고 생각함.
- dc official App
쉽게 이해가 안가는데, 아예 객체지향을 쓰지 말라는게 아니라면 객체에 멤버 변수를 쓰지 말라는 건 아예 변화하는 상태값/속성을 쓰지 말라는 거 아님?
아니 밖으로 그런거 노출시키지 말라고
객체 외부에서 접근할 수 있는 상수, public 멤버같은 개념이 애초에 존재하지 않아야 한다고 생각함 - dc App
전통적인 객체지향에서 속성을 참조 못하는 게 말이 됨?
내가 볼 땐 그건 그냥 "객체지향하지 말고 함수형을 하세요" 아니면 "함수형과 혼합한 새로운 패러다임이 필요하다" 정도의 이야기 같다. 그 말이 맞는지 틀리는지 떠나서, 자바나 C#은 전통적인 객체지향 패러다임에 최적화된 언어이고, 그런 전제라면 상태 노출하지 말라는 건 말이 안된다.
Encapsulation 이랑 정보은닉은 어따가 팔아드셨어요 getter setter 가 그거에 전면 위배되는데
223.62 // 차단했다면서 내 글은 어떻게 보고 답글다냐? 그리고 애초에 게터/세터가 나온 이유가 뭔데 개소리냐; 그냥 프갤가서 하던대로 땔감이나 까고 놀아. 괜히 알지도 못하는 토론에 억지로 끼어 보려고 뻘소리 하지 말고.
223.62는 통피임니다..
그렇군... 근데 뜬금 개소리로 딴지 거는 거 보니 의심은 가네.
get_area라고 했을때 area라는 변수를 가지고 있는건지 호출할때마다 구하는지 감춰진거임
외부적으로는 그런 구현과 분리가 게터, 세터 쓰는 이유 중 하나인데, 아예 객체에 멤버 변수를 안만들겠다면 그건 또 다른 문제잖아.
그러니까 외연적으로 봤을때 필요하지 않다고. 그리고 나는 읽기전용으로 하자고 주장한적 없음 - dc App
본문에 "멤버 변수가 필요 없다"라고 그렇게 이해한거지. 그럼 대충 세터는 필요 없다 정도로 이해하면 되는 거임? 상태 변경은 비즈니스 케이스 마다 메서드 뽑아서 하고? 크게 보면 그게 아래 언급한 DDD 케이스인데, 그건 특정 아키텍쳐잖아?
굳이 따지자면 DDD 같은 거 하면서 모든 걸 다 읽기 전용 데이터 클래스/구조체 같은 만 쓰는 메서드로 구현하고 변화하는 상태는 도메인 내부에서 엔티티에만 적용하는 그런 정도가 떠오르는데, 그건 특정 설계 사례/아키텍쳐이지 일반화할 내용은 아니라고 본다.
언어의 문제를 지적하는 거임. 프로그램 설계는 개발자 몫이지. - dc App
예를들어서 상위 클래스에서 멤버 변수를 박아놨는데, 하위 클래스에서는 그거를 getter로 처리해야 한다면 골아플꺼아님? 근데 멤버 변수나 getter setter나 할수 있는 일이 같잖음. 할수 있는건 똑같은데 확장성만 떨어지는거 아님? - dc App
그러니까 언어수준에서 객체의 외부에서 접근 가능한 멤버변수같은 개념을 없애버리고 모든걸 인터페이스(메서드) 만으로 표현해야 옳다고 생각함 - dc App
맞는 말임. getter setter로 private한 멤버 변수를 제공할 바엔 애초에 public으로 만들면 됨
일단 멤버 변수와 게터 세터가 할 수 있는 일이 같은게 아니지. 아까 예시로 든 하위 유형에서 세터를 확장해서 입력값 검증을 하거나 훅을 넣는 경우도 있고, 애초에 그런거 하라고 만든 개념이 게터 세터잖아?
ㅇㅇ 다르지. 정확히는 getter setter가 할 수 있는게 멤버 변수가 할 수 있는 일의 superset이지. 그러니까 멤버변수라는 개념을 없애자는 말임. getter setter가 불편한건 그냥 문법의 문제고. - dc App
딱히 확장할 필요도 없을 것 같은 클래스 의미없게 게터 세터 넣는 게 나쁘다면 어느 정도는 이해할 수 있어. 근데 니 말대로 지금은 특정 케이스의 설계를 말하는게 아니라 언어 자체를 비판하는 거니까, 게터 세터가 필요없다고 하려면 그런 예외가 있으면 안되는거지.
그런 건 따로 메소드를 만들면 되는 일일뿐, getter setter에서 그런 일을 하는 것 자체가 설계 오류 아닐까요. 말그대로 멤버 변수의 값을 얻거나 세팅하는 것 외에 다른 일을 하면 그건 getter setter가 아닌 거지
안되는건 아니지 super.getter로 읽어와서 this.getter로 처리한 다음에 결과를 내놓으면 되니까
전통적 OOP라는 전제도 인정하고, 그런 테두리 않에서 게터/세터가 하는 역할도 인정한다면 니 말대로 멤버 변수에 대한 문제만 남는데... 그런 맥락에선 멤버 변수는 지역 변수하고 다른 건 그냥 스코프 문제일 뿐이잖아? 객체의 변화하는 상태를 멤버 수준 스코프 변수가 아닌 방식으로 표현하는 게 어떤 방법이 있을까?
아니 내가 언제 게터세터가 필요없다고 주장함 ㅋㅋ 멤버가 필요없다고 했지 - dc App
나는 게터 세터가 아니라 게터 세터를 그렇게 불편하게 쓴다는 점하고 멤버 변수를 비판하는건데 - dc App
OOP라는 것 자체가 현실 세계에 있는 걸 최대한 코드에 녹여내서 현실을 잘 반영할 수 있도록 만들기 위해 나온 건데 멤버 변수를 없애면 OOP의 의의도 없어지는 거라... 멤버 변수를 없애도 코딩은 할 수 있고 그만큼 부수효과도 줄어들겠지만 그럴꺼면 함수형 패러다임을 하겠죵?
객체 구현에서 멤버변수를 쓰던 뭘하던 자기 마음인데, 객체의 속성을 참조하는 방법이 멤버변수와 게터 세터로 이분화되서 사용성이 떨어진다고 하는 말임. 이걸 막으려면 private 멤버변수만 허용하고 public 멤버변수를 금지하되(애초에 언어 기능에서 빼자는 말임), getter setter를 편하게 쓸 수 있는 문법이 필요하겠지 - dc App
근데 getter setter뿐만이 아니라 언어 전반적으로 문법이 장황한걸 getter setter의 문제로만 볼게 아니라는 말이고. - dc App
그게 Lombok이 아닐까? ㅎㅎ 애초에 그런게 언어 자체 기능이면 좋겠지만 90년 후반에 거기까지 생각하긴 어려웠겠지.
Lombok은 게터 세터와 관련해서 특화된 기능 아님? 나는 그게 언어에 내재되지 않은 기능이라서가 아니라, 모든 상황에 대한 보편적인 해결책이 아니라서 불완전하다는 말인데 - dc App
public 멤버 변수를 언어에서 막자는 건 충분히 생각할 수 있다고 본다. 근데 그렇게 하는 사례가 많은 것도 아닌데 (범용 언어 중에 있기는 함?) 안했다고 욕먹을 문제는 아니지 않을까?
아까 니가 말한 "private 멤버 변수만 허용하고 게터 세터를 편하게 쓸 수 있는 문법"이란 건 결국 롬복 같은 게 아닌가 하는거지.
그러니까 문법에 관해서는 게터 세터만이 아니라 언어 전반적으로 지적하는거라고. 일상적인 구문들도 오버헤드가 넘치는데 게터세터는 그게 유독 튀어보여서 지적받은것 뿐이지. 하이레벨 OOP언어가 C++에서 제공하는 문법적 기능에서 거의 달라지지 않는건 편리함보다 익숙함을 지향한 결과라고 생각함. - dc App
글쎄... 자바 문법이 장황하다는 건 이론의 여지가 없는 말인데, 나온지가 20년이 넘는 언어라면 그건 이해할 수 있는 부분이 아닐까? 더구나 롬복 같은 대안도 툴지원 완벽하고 널리 쓰이는 중이고, 게터/세터 자체는 이후에 나온 범용 언어들도 니가 제안하는 식의 극단적인 접근(예컨대 public 멤버 금지)은 안하고 있잖아?
PL의 세계란 정말이지 어렵군요
구체적인 예시를 들어볼께. 좀 작위적이긴 한데, 게시판에서 Post라는 클래스가 있고, 그걸 상속하는 ImagePost라는게 있다 치자. 근데 비즈니스 규칙이 짤방 게시물엔 본문을 특정 글자 수 이상 넣을 수 없다라고 한다. 그럼 그 비즈니스 규칙을 어디에 표현하는 게 가장 합리적일까? 전통적 OOP라면 ImagePost.content의 속성의 세터에 그런 제약을 구현하는게 이상적이라고 본다. 그래야 참고하는 곳 마다 규칙을 반복해서 찾기 어렵고 수정할 때 오류 생기는 식의 문제를 방지할 수 있으니까.
물론 이걸 코드로 표현하는 설계 방법이 이 것만 있는 건 아니지만, 전통적 OOP는 저런 접근을 기본으로 하는 것이고 자바나 C# 같은 언어는 그 전제로 게터나 세터 같은 개념을 만든 거지.
그래서 패러다임이나 전통적 설계 방식 자체를 비판하는 거라면 모를까, 그걸 인정하면서 게터나 세터의 존재를 언어의 문제라고 하기엔 좀 근거가 부족한 것 같다.
여담인데, 이런 걸로 덧글 20개 넘어가고, 또 그러면서 비꼬고 욕하는 넘 없는 건 맘에 든다... 프갤에서 넘어오길 잘한 듯 ㅎㅎ
해당 댓글은 삭제되었습니다.
하던대로 프갤가서 땔깜이나 까고 놀아. 거긴 나 같은 사람이 어그로 취급 받고, 너 같은 애들이 정상인 취급 받는 동네잖아.
내가 디씨하면서 느낀건데 진짜 차단하는 사람 못봄, 상대방 상처받으라고 차단했다고 하는거임
굳이언급하는 이유도 상대방 상처받으라고 하는거 ㅇㅇ
진짜 차단했으면 조용히갈길감
이거보셈, 벌써 뜨끔해서 풀발기해서 댓글다는중임
나에게 모든 행동을 읽혀서 당황하는모습임
내가 이 유동을 화나게 만들었다! 나는 감정을 조종할 수 있다!
나는 사도 마조히즘이다!
차단박았으면 무시를 하던지 차단박고 지 할말만 하는거 ㄹㅇ 역겹네. 현실에선 차단 박고 니 할말만 못 할텐데 어떡하냐
자강두천 그만하시고 병먹금하세요 아시겠어요?
추하다 유동아
상황에 따라 다른거지 무조건 public 없앤다 이런건 너무 극단적이야
별로 그렇지 않다고 생각함. 기존에 되던걸 못하게 하는건 보수적일 수 있는데, public 멤버는 게터 세터 기능의 진부분집합이잖아. 달라지는건 문법하고 이분화된걸 통합한다 뿐인데 문제가 될게 있음? - dc App
게터/세터는 메소드잖아 세터/게터가 내부적으로 재귀적으로 호출되면 헬인데
게터/세터 안에서 유효성 검사같은걸 실행하는데 그걸 피하고 싶으면 또 다른 메소드를 만들어야될테고
성능 문제때문에? 애초에 동적 디스패칭을 너무 난발하는거 아닌가 싶은데. 상황에 따라서 컴파일러가 정적 디스패칭으로 처리해줄 수 있지 않을까 - dc App
변수/메소드 의미 차이랑 동적 디스패칭은 상관없지 모든 퍼블릭 변수를 없애고 게터/세터를 붙이는것보다 코틀린식으로 게터/세터가 있는 변수를 퍼블릭처럼 쓸수있는게 더 편하고 일관성있어보임
아니 재귀호출이 헬이라길래 성능문제 때문에 언급하는줄 알았지. 그리고 나는 코틀린식 해법도 부정하지 않음. 객체에 대한 접근 방법이 멤버변수하고 게터세터로 나뉘는게 문제라거 생각하는거니까, 멤버변수가 게터세터의 syntactic sugar가 되면 아무 문제 없다고 생각함 - dc App
C#에서 멤버변수를 없애고 값은 프로퍼티를 통해서만 접근할 수 있게 하자 이런거였네요 댓글보고 이해함. 문법 더러운것과 별개로 멤버변수 접근할때 직접 접근하는것과 getter setter 쓰는것 두가지 방법이 있는건 문제가 맞는 것 같긴 함