- 인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스가 있음
class Point {
public double x;
public double y;
}-
이런 클래스에선
public이어선 안됨, 데이터 필드에 직접 접근할 수 있어도 캡슐화의 이점을 제공하지 못함 -
API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없음
-
이럴 때는 필드를 모두
private으로 바꾸고public접근자(getter)를 추가함
class Point {
private double x;
private double y;
public Point(double x, double y) {
this.x = x;
this.y = y;
}
public double getX() { return x; }
public double getY() { return y; }
public void setX(double x) { this.x = x; }
public void setY(double y) { this.y = y; }
}-
public클래스에서라면 이 방식이 확실히 맞음, 패키지 바깥에서 접근할 수 있는 클래스라면 접근자를 제공함으로써 클래스 내부 표현 방식을 언제든 바꿀 수 있는 유연성을 얻을 수 있음 -
public클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생겨날 것이므로 내부 표현 방식을 마음대로 바꿀 수 없게 됨 -
하지만
package-private클래스 혹은private중첩 클래스라면 데이터 필드를 노출한다 해도 하등의 문제가 없음, 그 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 됨 -
public클래스의 필드가 불변이라면 직접 노출할 때의 단점이 조금 줄어들지만 좋은 생각은 아님, API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전함,getter를 통해서 쓰는게 좋음 -
단, 불변식은 보장할 수 있게 됨
캡슐화
아이템 16의 포인트는 결국 public 방식은 물론 쓰는 입장에서 데이터 접근을 별로 어렵지 않게 처리하고 쓸 수 있지만 이건 정말 1차원적인 생각에 불과하다고 볼 수 있음
아무리 인스턴스 필드만 모아둔다고 하더라도 이것이 마구잡이로 접근해서 쓰거나 처리하고 내가 쓰기 편한 것은 결국 객체 지향 프로그래밍의 이점과 캡슐화 등 아무것도 살리지 못하는 원초적인 부분이 됨
그래서 캡슐화 자체가 private 제어자를 붙이고 멤버변수 통제 상황에서 getter/setter 를 통해서 메서드화 하여서 잘 활용하는 것이 중요한 것임
이런식으로 은닉화를 잘 활용하면 큰 무리가 없음
