[Effective-Java] Item 16. public 클래스에서는 public 필드가 아닌 접근자 메소드를 사용하라

인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 클래스를 작성하더라도 필드에 public을 사용하지 말자.

 

// 사용 X
class Point {
    public double x;
    public double y;
}

// 사용
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; }
}

 

이유는 다음과 같다.

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

따라서 위의 코드처럼 public getter나 setter를 이용하자.

패키지 바깥에서 접근할 수 있는 public 클래스라면 접근자를 제공함으로써 클래스 내부 표현 방식을 언제든 바꿀 수 있는 유연성을 얻을 수 있다. public 클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생겨나서 내부 표현 방식을 옳지않게 사용하게 된다.

 

 

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

클래스가 표현하려는 추상 개념만 올바르게 표현해주면 된다.

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

 

package-private: 이 클래스를 포함하는 패키지 안에서만 동작하니 패키지 바깥 코드는 전혀 손대지 않고데이터 표현 방식을 바꿀수 있다.

private 중첩 클래스: 수정 범위가 더 좁아져서 이 클래스를 포함하는 외부 클래스까지로 제한되기에 수정이 더 간편하다.

 

java 플랫폼 라이브러리에도 public 클래스의 필드를 public으로 노출시켜 심각한 성능 문제를 가졌다.

 

 

public 클래스의 필드가 불변이라면 직접 노출할 때의 단점이 줄지만 좋은 생각은 아니다.

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

 

 

 

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

package-private 클래스나 private 중첩 클래스에서는 종종 필드를 노출하는 편이 나을때도 있다.

 

 

* 위 글은 EffectiveJava 3/E 책 내용을 정리한 글로, 저작권 관련 문제가 있다면 댓글로 남겨주시면 즉각 삭제조치 하겠습니다.