[이펙티브자바 3판] ITEM16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

이번장의 핵심은...

public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다

불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다

하지만, package-private 클래스나 private 중첩 클래스에서는

종종 (불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다

---

우선 아래의 퇴보한 클래스를 보자

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

왜 퇴보한 클래스인가?

단순히 인스턴스 필드들을 모아놓는 일 외에는 아무 목적이 없는 퇴보한 클래스이다

데이터 필드에 직접 접근할 수 있으니 캡슐화 이점도 없다

API를 수정하지 않고도 내부 표현을 바꿀 수 있고, 불변식을 보장할 수 없다

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

또한 이처럼 퇴보한 클래스는 public 이어서는 안 된다

 

캡슐화

위 클래스 필드를 모두 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 클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생겨나므로 함부로 내부 표현 방식을 바꿀 수 없다

하지만, package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출한다 해도 문제는 없다

 

이 방식이 클래스 선언 면에서나 이를 사용하는 클라이언트 코드 면에서나 접근자 방식보다 훨씬 깔끔하다

패키지 바깥 코드는 전혀 손대지 않고도 데이터 표현 방식을 바꿀 수 있다

 

public 클래스의 필드가 불변일 때, 직접 노출하면 괜찮을까?

단점은 조금 줄어들지만, 여전히 결코 좋은 생각이 아니다

API를 변경하지 않고는 표현 방식을 바꿀 수 없고,

필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전하다

단, 불변식은 보장할 수 있다

아래 클래스를 보면 각 인스턴스가 유효한 시간을 표현함을 보장한다

public final class Time() {
	private static final int HOURS_PER_DAY = 24;
	private static final int MINUTES_PER_HOUR = 60;
	
	public final int hour;
	public final int minutes;
	
	public Time(int hour, int minute) {
		if(hour<0 || hour >= HOURS_PER_DAY)
			throw new IllegalArgumentException("시간 : " + hour);
		if(minute<0 || minute >= MINUTES_PER_HOUR)
			throw new IllegalArgumentException("분 : " + minute);
		this.hour = hour;
		this.minute = minute;
	}
}