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

아이템 16

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

인스턴스 필드들을 모아놓는 클래스를 작성할 때, public으로 지정해서는 안된다. 예를 들어, 아래와 같은 클래스를 의미한다.

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

이렇게 작성하게 된다면,
(1) 데이터 필드에 직접 접근 가능, 캡슐화 이점 제공 못한다.
(2) 불변식을 보장할 수 없다.
(3) 외부에서 필드를 접근할 때 부수 작업을 수행할 수도 없다
(4) API를 수정하지 않고는 내부 표현을 바꿀 수 없다. (객체의 내부가 바뀌어도 객체의 사용방법이 바뀌지 않아야 좋은 설계 방법)

따라서 private으로 지정하고 getter를 추가한다.

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

    public Time(int hour, int minute) {
        if (hour < 0 || hour >= HOURS_PER_DAY) {
            throw new IllegalArgumentException("시간: " + hour);
        }
        if (minute < 0 || minute >= HOURS_PER_HOUR) {
            throw new IllegalArgumentException("분: " + minute);
        }        
        this.hour = hour;
        this.minite = minute;    
    }
	...
}

캡슐화

https://siyoon210.tistory.com/33

캡슐화의 장점

• 사용자가 불필요한 부분을 접근하지 못하게 하여, 객체의 오용을 방지 할 수 있습니다. (항상 개발자와 사용자가 다를 수 있음을 기억해야 합니다.)
• 객체의 내부가 바뀌어도 그 객체의 사용방법이 바뀌지 않습니다. (사용자는 객체 내부가 바뀌어도 같은 결과를 기대 할 수 있습니다.)
• 객체 내부에서 사용되는 데이터가 바뀌어도 다른 객체에게 영향을 주지 않습니다. (각 객체들의 독립성이 유지됩니다.)
• 객체간의 결합도가 낮아지게 됩니다. (객체간의 결합도를 낮추는 일은 객체 설계의 기본 원칙입니다.)
• 큰 시스템 일지라도 컴포넌트 별로 작게 분리하여 개발이 가능하게 됩니다. 이로 인하여 시스템 개발 속도를 높이고 성능을 최적화 하기가 쉽습니다.

정리

public 클래스는 가변 필드를 직접 노출해서는 안 된다. 불변 필드는 노출해도 덜 위험하지만 완전히 안심할 수는 없다.