[💬] 게터세터 쓰는 이유 (수정)

[살구안즈(salguanz)]

크게 세 가지가 있음. 정보은닉, 코드유연성, 코드추적

[1. 정보은닉]

버튼을 누르면 공짜로 음료수를 주는 자판기가 있다고 하자.

Buy() 메소드를 호출하면 재고량이 하나씩 줄어드는 간단한 클래스임

하지만 알다시피 여기엔 문제점이 있음

굳이 Buy() 메소드를 거치지 않아도 drink 변수의 값을 수정할수 있음

오직 누군가가 버튼을 눌렀을 때만 재고량이 감소하길 원하므로

보통 drink 변수를 private로 선언하여 외부에서의 접근을 차단하는 것으로 원하는 기능을 구현함

거의 대부분의 필드(멤버변수)는 이렇게 외부에서 접근하지 않기를 원하는 정보들이 대부분이고

그래서 객체지향에는 public, protected, private 같은 접근제한지시자 개념이 존재하는 거임

어 그런데 현재 재고량은 확인할 수 있었으면 좋겠음

외부에서 drink를 수정은 못하게 하고 그냥 값만 얻을 수 있으면 좋겠음

그래서 GetDrink() 메소드를 만듬

이게 바로 게터임

[2. 코드유연성]

재고량을 다시 충전할 수 있도록 Add 메소드를 만들었음

그리고 품절여부를 나타내는 정보를 추가하고

drink가 0이면 Buy() 메소드가 실행되지 않게 함

아 근데 재고량이 바뀔때마다 로그를 출력해서 현재 재고량이 항상 화면에 나오길 원함

그래서 또 고침

문제점.

중복코드가 늘어나고, 기능하나 추가하려고 Buy() 메소드와 Add() 메소드를 함께 수정하고 있음

만약 코드가 더 복잡해진다면 점점 헤깔리다가 빼먹는 부분도 분명 생길거임

우리 인붕이들의 코드가 스파게티가 되는 이유임

해결.

SetDrink() 라는 메소드를 만들고 거기서 로그출력과 품절여부를 모두 관리함

그리고 Buy()와 Add()는 SetDrink()를 호출함.

코드의 의미도 명확해졌고 앞으로 drink 변수가 수정될 때 할일이 있다면 그냥 SetDrink() 메소드만 수정하면 됨

이게 세터임.

[3. 코드추적]

프로젝트가 커지고 코드가 엄청 많아짐.

그런데 갑자기 drink 변수의 값을 수정하면 절대 안되는 걸로 사양이 바뀜.

다행 우리의 인붕쿤은 게터세터가 아무튼 좋다고들 하니까 이유는 모르겠지만 게터세터를 열심히 써왔음

드디어 인붕쿤은 그 노력의 보상을 받을 수 있게 된거임

세터를 죽여버렸더니 drink 값을 변경하는 부분은 전부 컴파일 에러가 발생함

다른거 신경쓸 필요 없이 저 부분만 고치면 됨

만약에 같이 작업하는 다른 인붕쿤이 있었다면 '너 이제부터 값 변경 하지마' 라고 강요하는 것도 가능할 거임

아무튼 경험적으로 게터세터는 존나 좋고, 그래서 쓰였는데

변수가 10개면 메소드는 20개가 지저분하다는 단점이 있음

C++이나 자바 코드 보면 클래스마다 몇백줄이 되는데 거의 대부분 게터랑세터임

그래서 C#에서 제공하는 문법적인 편의기능이 프로퍼티임

요약

1. 게터세터를 쓰면 코드가 유연해지고, 값 변경 추적이 쉬움

2. 그래서 애용되는 컨벤션이었는데 변수가 늘면 게터세터로 도배가 되는 문제가 있음

3. 그래서 C#은 프로퍼티라는 문법적 편의기능을 제공함

[듀콜다(duecorda)]

정성추. 그래서 코틀린 등은 private 선언하면 게터,세터가 내부에서 자동으로 만들어짐

[익명(124.50)]

일단 잘썼음. 근데 java 가 조오오올라 병신같은 이유 중 하나가 저딴짓거리임 ㅋㅋㅋ - dc App

[익명(124.50)]

배보다 배꼽이 크고 죄다 조오오오오온나 지저분함 ㅋㅋㅋㅋㅋ 객체지향의 가장 병신같은 구현예시가 java 가 아닐까 함 - dc App

[익명(58.124)]

보이스로이드 같은 색깔을 쓰네

[살구안즈(salguanz)]

[데쿠(hhw000)]

잘보겠습니다 감가합니다 - dc App