Theory/Programming Language

getter/setter를 올바로 사용하기

외부에서 내부의 상태를 변경할 때는 getter/setter를 사용하도록 한다.[각주:1]
변수를 직접 접근하도록 노출하지 않는다.
이름이 변경되지 않을 getter/setter를 공개한다.


변경될 가능성이 적은 getter/setter만 외부에 노출한다.

public 속성을 지닌 모든 것(클래스, 함수, 변수 등)의 의도는
"마음대로 접근하라."는 의미만 있는 것이 아니다.
"이름이 바뀌지 않는다."까지 포함한다.
바뀔 수도 있다면(예를 들면, 구현에 의존적이라면) public 속성을 주지 않는다.
이 클래스를 변경할 때, 이것을 사용하는 다른 어떠한 코드에도 영향을 줄 수 있기 때문이다.


getter/setter를 사용하면 일관된 접근 방법을 유지하면서 구현의 유연성까지 제공한다.

변수의 이름이나 규칙이 바뀔 수 있다면
setter/getter 같은 것을 한번 감싸는 것이 좋다.
예를 들면, "Null을 설정할 수 없다."라는 규칙이나,
불변성[각주:2]이 추가될 수 있다.

접근의 제약이 없고 변수명이 절대로 바뀔 일이 없으면
변수를 public으로 직접 공개해도 괜찮을 듯 싶다.

그러나, getter/setter와 변수 직접 접근을 섞어서 쓰면 코드가 더러워진다.
어떤 변수는 'h = now.getHours()'
다른 변수는 'm = now.minutes'를 사용하면 지저분하다.


getter/setter에 대한 오해

setter/getter 쓴다고 정보은닉이 되는 게 아니고 사실은 정보은닉을 망치게 됩니다.
저는 getter/setter 많이 쓴 것은 나쁜 냄새(bad smell)로 봅니다.
getter setter는 객체지향과 거리가 멀며 써야 할 곳은 한정되어 있다


문맥과 떨어져서 해석하면,
"getter/setter 보다는, 변수를 직접 노출하고 사용하는 것이 좋다"
라고 오해할 수 있다.


꼭 필요한 getter/setter만 공개한다.

내가 해석한 의도는
클래스 내부의 변수를 필요 이상으로 노출하는 설계는 나쁘다는 것이다.
그래야만 한다면 설계에 문제[각주:3]가 있다고 볼 수 있다.
공개된 getter/setter 뿐만 아니라 이와 마찮가지인 public 변수도 해당된다.
따라서, getter/setter 보다는 변수에 public을 주는 것이 좋다고 해석하면 안된다.

  1. 언어에서 제공하는 getter/setter 포함. 예를 들면, C#의 property [본문으로]
  2. getter/setter에서 사본을 생성하고 이를 반환하는 식으로 구현 [본문으로]
  3. 인용한 구절에서는 이를 나쁜 냄새라고 표현했다. [본문으로]
저작자 표시 변경 금지
신고

'Theory > Programming Language' 카테고리의 다른 글

getter/setter를 올바로 사용하기  (1) 2017.02.13
public, private 키워드가 필요한 이유  (0) 2017.02.08
  1. Favicon of https://justhackem.wordpress.com/2017/02/28/encapsulation-and-information-hidi.. 옮긴이 M/D Reply

    나는 응집 관점의 캡슐화 해석을 지지한다. Vector 클래스 설계법은 정보를 숨기지 않지만 이름을 가지기에 충분한 가치가 있기때문이다.
    https://justhackem.wordpress.com/2017/02/28/encapsulation-and-information-hiding/

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 98
Yesterday : 147
Total : 171,340