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

교재 : Effective java, 강의 : inflearn 백기선

---

public class Point { // 이처럼 퇴보한 클래스는 public이어서는 안 된다!
    public double x;
    public double y;
}

이런 클래스는 데이터 필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못한다. (아이템 15. 클래스와 멤버의 접근 권한을 최소화하라)

public 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 접근자(getter)를 추가한다.

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

publlic 클래스의 필드가 불변이라면 직접 노출할 때의 단점이 조금은 줄어들지만, 여전히 결코 좋은 생각이 아니다.

// 코드 16-3 불변 필드를 노출한 public 클래스 - 과연 좋은가? (103-104쪽)
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: " + hour);
        if (minute < 0 || minute >= MINUTES_PER_HOUR)
            throw new IllegalArgumentException("Min: " + minute);
        this.hour = hour;
        this.minute = minute;
    }

    // 나머지 코드 생략
}

API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전하다. 단, 불변식은 보장할 수 있게 된다.

package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출한다 해도 하등의 문제가 없다.
이렇게 책에 나와있지만, 데이터 필드를 접근할 때는 메서드를 통해 접근을 하는 것이 좋다.

자바 플랫폼 라이브러리에도 public 클래스의 필드를 직접 노출하지 말라는 규칙을 어기는 사례가 종종 있다.
대표적인 예가 java.awt.package 패키지의 Point 와 Dimension 클래스다.

Point : https://docs.oracle.com/javase/8/docs/api/java/awt/Point.html#x
Dimension : https://docs.oracle.com/javase/8/docs/api/java/awt/Dimension.html#height

이 경우 방어적 복사를 하기 위해 필드를 가져오는 곳에서 인스턴스를 새로 생성해야만 한다. 이는 성능 문제와 프로그래머의 귀찮음을 유발한다.