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

단순히 인스턴스 필드를 모아놓는 클래스는 public이면 안된다. 데이터 필드에 직접 접근이 가능해져 캡슐화의 이점을 제공하지 못하기 때문이다.

// public이면 안된다!!
class Point {
    public double x;
    public double y;

}

 

위와 같은 클래스는 API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다.

 

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

 

패키지 밖에서 접근할 수 있는 클래스라면 접근자를 제공함으로써 클래스의 내부 표현을 언제든 바꿀 수 있는 유연함을 얻을 수 있다.

public 클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생기기 마련이다. 이를 사용하는 클라이언트가 생기면 내부 표현방식을 마음대로 바꿀 수 없게 된다.

 

package-private 혹은 private 중첩 클래스라면?

package-private(default) 혹은 private 중첩 클래스라면 데이터 필드를 노출해도 문제가 없다. 그 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 된다.

클라이언트 코드가 클래스의 내부 표현에 종속된다는 문제가 있긴 하지만, 패키지 바깥 코드는 전혀 손대지 않고 데이터 표현 방식을 바꿀 수 있다는 장점이 있다.

장점

• 데이터 필드를 노출해도 문제 될 건 없다.
• 클라이언트 코드면에서 훨씬 깔끔해진다.
• 패키지 바깥 코드는 전혀 손대지 않고 데이터 표현 방식을 바꿀 수 있다.

 

public 클래스의 불변 필드 노출

불변 필드를 노출해도 덜 위험하지만 완전히 안심할 수는 없다. 단점이 조금 줄어들긴 하지만, 여전히 좋은 방법은 아니다. 불변식을 보장한다는 것 외에 장점이 없다.

public 클래스의 불변 필드 노출의 단점

• API 수정 없이 내부 표현을 변경하지 못한다.
• 외부에서 필드에 접근할 때 부수 작업을 수행할 수 없다.