일반 : 캡슐화와 관련하여 getter와 setter의 필요성

[qudtjs0753]

getter와 setter는 객체의 데이터를 밖으로 꺼내고 수정하게 만든다. private로 기껏 선언해놓고 외부에서 메소드로 접근 가능하게 하는 방식이 옳을까?? getter와 setter는 무슨 이유로 생겼을까?

[InHyeok-J]

해당 Question은 카테고리 -> 공통 Q&A로 이동할게요

[JoeSeongchan]

setter는 이유가 명확함. Valid한 데이터를 다루기 위해서. 외부에서 올바르지 못한 값을 속성값으로 설정하려 할 때, setter가 없다면 아무런 제한 없이 값 설정이 가능함.

그렇다고 해서 한 번 객체가 생성되면 속성값이 변경되지 않도록 하면(불변 객체), 객체 생성 비용이 너무나 커짐. (비효율)
성능을 위해 타협했다고 생각.

조성찬

[InHyeok-J]

Q. getter와 setter는 객체의 데이터를 밖으로 꺼내고 수정하게 만든다. private로 기껏 선언해놓고 외부에서 메소드로 접근 가능하게 하는 방식이 옳을까?? getter와 setter는 무슨 이유로 생겼을까?

*레퍼런스를 참고해서 한번 정리하려고 합니다.

캡슐화는 객체의 외부에서 객체의 상태를 알거나 변경할 수 없게 만들며 객체의 자율성이 증가될 수 있게 하며 변경에 변화를 받지 않게 하는 OOP의 개념이다.
주로 객체의 상태를 접근 제한자를 활용해 접근을 제한하고(private) 외부에서의 접근을 제한한다.

하지만 대부분 개발을 할때 Lombok 어노테이션을 사용해서 @Getter, 혹은 @Setter 을 아무 고민 없이 사용하거나, IDE에서 자동으로 만들어서 사용하는 등 고민을 하지 않고 무지성 getter, setter을 사용할 때도 있다.

이것을 고민한 개발자는 getter, setter의 사용을 지양하면서 개발을 하지만 외부에서 접근이 필요할 때 사용하고 싶은 충동에 휩싸이거나 아예 사용하지 않게 노력하며 캡슐화를 지킨다는 명목하에 코드의 복잡성이 증가하게 된다.

해당 질문은 위와 같은 상황과 관련해서 private로 선언해서 접근제한을 막았지만, 메소드로 외부 접근을 허용하면 아무런 의미 없지 않나? 라는 의문과 고민에서 발전한것 같다.

Q. getter(setter)를 왜 사용하는 것 일까?

주로 getter(setter)을 사용하는 이유는 데이터의 무결성을 위해서라고 한다. 만약 객체의 상태를 누군가 직접 수정을 한다면 어떻게 될까?
public String phoneNo 라는 휴대폰 번호를 뜻하는 속성이 있다고 가정하며, 해당 값의 정확한 형태는 "010-xxxx-xxxx"여야 한다.
하지만 누군가 Entity.phoneNo = "번호" 라는 정확하지 않은 값을 막 넣을 수 있다면 ? 객체의 해당 속성의 정확성은 깨지며 신뢰할 수 없는 속성을 유지하게 된다.
하지만 setter("번호")이라는 메서드에서 해당 파라미터의 값을 변경시에 검증하는 로직을 추가한다면 최소한 해당 속성의 무결성은 보장받을 수 있게 된다.
그 외의 이점은 링크 참고.

Q. getter(setter)가 있다면 어떻게 될까?

OOP 의 기본 원칙은 객체가 구현의 세부 사항을 외부에 노출하면 안된다는 것이다. 이렇게 하면 해당 객체를 사용하는 코드를 변경하지 않고 구현을 변경할 수 있다. 하지만 getter(setter)는 대부분의 경우 구현 세부 정보에 대한 접근을 할 수 있게 한다.

예를들어 getX() 라는 메소드가 1000개의 다른 객체가 호출한다고 가정한 상황에서, getX()는 int 형을 반환한다고 하자.
하지만 시간이 흘러서 X의 타입이 int가 아닌 long으로 변환해야 한다고 하면 1000개의 컴파일 오류가 발생한다. (캐스팅을 한다면 값이 누락될 수 있다.)
OOP의 기본 원칙인 데이터 추상화가 위배되며 그래서 우리는 private의 인스턴스 변수와 getter의 사용을 지양하려고 한다.

Q. getter(setter)를 사용해야 할까?

(인용)

getter와 setter가 있다고 해서 캡슐화가 깨지는 것은 아니다. 캡슐화를 깨트리는 것은 아무 생각 없이 모든 멤버 변수에 대한 getter와 setter을 만드는 것. 해당 방법은 public한 멤버 변수보다는 낫지만, 좋은 방법은 아니다.
캡슐화는 객체 외부에서 객체의 상태를 알거나 변경할 수 없어야 한다는 것이 아닌, 이를 수행하기 위한 합리적인 정책이 있어야 한다는 것이다.

• 일부 데이터는 완전히 내부에 있을 수 있으므로 getter와 setter가 없어야 한다.
• 일부 데이터는 읽기 전용이여아 하므로 getter는 필요하지만 setter는 필요하지 않을 수 있다.
• 일부 데이터는 서로 일관성을 유지해야 하므로, 각각의 setter를 만들지 않고, 동시에 설정하거나 단일 방법을 제공해야 한다.
• 일부 데이터는 특정 방식으로만 변경해야 할 수 있다. 이 경우 setter 가 아닌 increment() or decrement()가 있어야 한다

---

정리) + 생각
위 인용글에서 집중해야 할 것은 합리적인 정책이다. 해당 객체 내부의 값을 조회하거나 수정하기 위한 합리적인 근거를 기반으로 getter,setter을 사용해야 한다.
사람이라는 객체의 나이라는 속성의 값을 증가하거나 감소할때 setAge(value)라는 아무런 정책 없는 setter 보다 , gettingOlder()라는 메소드로 해당 객체의 속성을 변경한다면 setter처럼 값을 변경하지만 정책이 녹아들은 메소드의 활용이 내부 구현을 숨기면서 값을 변경한다고 생각한다

reference

https://stackoverflow.com/questions/34805276/do-setter-and-getter-methods-breaks-encapsulation
https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html