item 16 public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

ITEM 16 public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

---

public 클래스

인스턴스 필드를 모아놓는 퇴보한 클래스

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

이런 클래스가 public 이라면 데이터 필드에 직접 접근이 가능하여 캡슐화의 이점이 없어진다

데이터 필드에 직접 접근이 가능해지면 아래와 같은 문제가 생긴다

• api를 수정하지 않고서는 내부 표현 변경이 불가능하다
• 불변식을 보장할 수 없다
• 외부에서 필드에 접근 할 때 부수 작업을 수행할 수 없다

철저한 객체지향 프로그래머는 아래와 같이 작성한다

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; }

}

• 필드를 모두 private 으로 작성
• public 접근자를 추가
• 패키지 바깥에서 접근 할 수 있는 클래스이기 때문에 접근자를 제공
• 클래스 내부 표현 방식을 유연하게 수정 가능

package-private 클래스, private 중첩 클래스

• 데이터 필드를 노출해도 문제가 없다
• 클래스가 표현하려는 추상 개념만 올바르게 표현 해주면 된다
• 클래스 선언 측면, 클라이언트 코드 측면 모두 접근자 방식보다 훨씬 깔끔하다
• 클라이언트 코드가 이 클래스 내부 표현에 묶이지만 클라이언트도 이 클래스를 포함하는 패키지 안에서만 동작하는 코드라 상관없다
  • 패키지 바깥 코드 변경 없이 데이터 표현 방식을 수정 가능
• private 중첩 클래스라면 수정 범위가 더 좁아져 이 클래스를 포함하는 외부 클래스까지로 제한된다

정리

• public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다
• 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다
• package-private 클래스나 private 중첩 클래스에서는 종종 (불변이든 가변이든) 필드를 노출하는 편이 나을때도 있다