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

퇴보한 클래스

인스턴스 필드를 모아놓는 일 외에는 아무 목적이 없는 클래스

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

• 데이터 필드에 직접 접근 -> 캡슐화의 이점 X
• API를 수정하지 않고는 내부 표현을 바꿀 수 없음
• 불변식을 보장 못함
• 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다.

접근자를 사용한 public 클래스

필드를 모두 private으로 바꾸고 public 접근자(getter)를 추가

// 접근자와 변경자(mutator) 메서드를 활용해 데이터를 캡슐화한다.
class Point {
	public double x;
    public 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() { this.x = x; }
    public void setY() { this.y = y; }

}

• public 클래스에서의 옳은 방법
• 접근자를 제공함으로써 클래스 내부 표현 방식을 언제든 바꿀 수 있음 (유연성 획득)

private 클래스의 경우

package-private 클래스 혹은 private 중첩 클래스의 경우

• 데이터 필드를 노출해도 문제가 없다.
  • 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 된다.
• 접근자 방식보다 훨씬 깔끔하다
  • 클래스 선언 면에서
  • 사용하는 클라이언트 코드 면에서
• 클라이언트 코드가 이 클래스 내부 표현에 묶이지만!
  • 클라이언트도 어차피 이 클래스를 포함하는 패키지 안에서만 동작하는 코드다.
    --> 패키지 바깥 코드는 전혀 손대지 않고도 데이터 표현 방식을 바꿀 수 있다!

안 좋은 예시

public 클래스의 필드를 직접 노출하지 말라는 규칙을 어긴 사례

• java.awt.package의 Point와 Dimension (아이템 67 참고)
• 타산지석으로 삼자

---

핵심 정리

• public 클래스는 절대 가변 필드를 직접 노출해서는 안된다.
  • 불편 필드여도 (ex Time class의 hour, minute 필드) 완전히 안심하지 말자
• package-private or private 중첩 클래스에서는 필드를 노출하는 편이 나을 때도 있다.