[Effective Java 3E] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

💥 개요

이따금 인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려 할 때가 있습니다.

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

이런 클래스는 데이터 필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못합니다. API를 수정하지 않고 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없습니다.

철저한 객체 지향 프로그래머는 이런 클래스를 싫어해 모두 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 중첩 클래스라면 데이터 필드를 노출해도 아무런 문제가 없습니다. 그 클래스가 표현하려는 추상 개념만 올바르게 표현 해주면 됩니다. 이 방식은 클래스 선언이나 클라이언트 코드나 접근자보다 훨씬 깔끔합니다.

클라이언트 코드가 이 내부 표현에 묶이지만, 클라이언트도 패키지 안에서만 동작하는 코드일 뿐이기 때문에 패키지 바깥 코드는 전혀 손대지 않고 데이터 표현 방식을 바꿀 수 있습니다. (private 중첩 클래스의 경우라면 수정 범위가 더 좁아져 클래스를 포함하는 외부 클래스까지로 제한됨)

 

☠️ Java 플랫폼 라이브러리에서의 나쁜 예

자바 플랫폼 라이브러리도 public 클래스를 필드에 직접 노출하지 말라는 규칙을 어기는 사례가 있습니다. (따라하면 안됨)

대표적인 예로 java.awt.package 패키지의 Point와 Dimension 클래스입니다. 이 클래스들의 심각한 성능 문제는 오늘까지도 해결되지 못했습니다.

Java 17 Point Class(java.awt.package)

 

🔍 불변 필드를 노출한 public 클래스

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

public 클래스의 필드가 불변이라면 직접 노출 할 때 단점이 줄어들지만, 여전히 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 할 수 없는 단점은 여전합니다. 단, 불변식은 보장하게 됩니다.

 

public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다. 불변 필드라면 노출해도 위험은 덜 하지만 완전히 안심할 수 없다. 하지만 package-private 클래스나 private 중첩 클래스에서는 종종 (불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다.
그냥 노출하지 않고 private + getter 사용하는게 좋을 것 같습니다.

 

 

❤️ 스터디 질답 정리

Q.Point와 Dimension 클래스 왜 성능 문제인가?
A.사용하는 클라이언트에서 public field라는 설계 문제가 있어서, 새로 생성자를 통해 방어적 복사를 해야해서 계속 불필요한 객체를 만들어내니까 성능 문제.

getter setter는 객체지향 측면에서 좋지 않다.
getter는 dto로 넘겨줄때만 써야하고 setter는 불변 객체를 만드는 습관을 들이기 위해 쓰지 말아야 한다.

getter setter는 메시지를 전달하는 방식이 아니다.