아래는 안좋은 class의 예다.

class Poing {
	public double x;
	public double y;
}

이런 클래스는 데이터 필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못한다. 아래의 내용을 확인하자

• API를 수정하지 않고는 내부 표현을 바꿀수 없다.

  class Point {
      private double r;
      private double theta;
  }
  

  이렇게 바꾸고 싶으면 이미 외부에서는

  p.x = 10;
  System.out.println(p.y);
  

  위와 같이 쓰고 있기 때문이다.

• 불변식을 보장할 수 없다.

  Point p = new Point();
  p.x = Double.NaN;
  p.y = Double.POSITIVE_INFINITY;
  

  현재 코드에서는 검증할 기회가 없고 값이 바뀌는 순간을 통제하지 못한다. 만약 setter가 있다면?

public void setX(double x) {
    if (Double.isNaN(x)) throw ...
    this.x = x;
}

최소한 규칙을 강제할 수 있다.

• 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 있다.

  부수 작업으로 로그, 캐시 무효화, 이벤트 발생 등등…

  public void setX(double x) {
      this.x = x;
      recalcDistance();
      logChange();
  }
  

  setter였다면 확장 가능성을 확보 할 수 있다.