아이템 15. 클래스와 멤버의 접근 권한을 최소화하라

어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔하게 분리한다. 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작방식에는 전혀 개의치 않는다. 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다.

정보 은닉의 장점

정보 은닉의 장점은 정말 많다. 그중 대부분은 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해주는 것과 연관되어 있다.

시스템 개발 속도를 높인다.

여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.

시스템 관리 비용을 낮춘다.

각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화할 수 있기 때문이다.

소프트웨어 재사용성을 높인다.

외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않은 낯선 환경에서도 유용하게 쓰일 가능성이 크기 때문이다.

큰 시스템을 제작하는 난이도를 낮춰준다.

시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.

접근 제한자

• 자바는 정보 은닉을 위한 다양한 장치를 제공한다. 그중 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)을 명시한다.
• 각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자(private, protected, public)로 정해진다. 이 접근 제한자를 제대로 활용하는 것이 정보 은닉의 핵심이다.

기본 원칙

기본 원칙은 간단하다. 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다. 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다는 뜻이다.

• (가장 바깥이라는 의미의) 톱레벨 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private과 public 두 가지다.
• 톱레벨 클래스나 인터페이스를 public으로 선언하면 공개 API가 되며, package-private으로 선언하면 해당 패키지 안에서만 이용할 수 있다.
• 패키지 외부에서 쓸 이유가 없다면 package-private로 선언하도록 한다. 그러면 이들은 API가 아닌 내부 구현이 되어 언제든 수정할 수 있다.
• 반면, public으로 선언한다면 API가 되므로 하위 호환을 위해 영원히 관리해줘야만 한다.

한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시켜보자.

• 톱레벨로 두면 같은 패키지의 모든 클래스가 접근할 수 있지만, private static으로 중첩시키면 바깥 클래스 하나에서만 접근할 수 있다.
• public 클래스는 그 패키지의 API인 반면, package-private 톱레벨 클래스는 내부 구현에 속한다. 따라서 가능한 한 public일 필요가 없는 클래스의 접근 수준을 package-private
  톱레벨 클래스로 좁혀야 한다.

멤버와 접근 수준

멤버(필드, 메서드, 중첩 클래스, 중첩 인터페이스)에 부여할 수 있는 접근 수준은 네 가지다.

• private : 멤버를 선언한 톱레벨 클래스에서만 접근할 수 있다.
• package-private : 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 접근 제한자를 명시하지 않았을 때 적용되는 패키지 접근 수준이다(단, 인터페이스의 멤버는 기본적으로 public이
  적용된다).
• protected : package-private의 접근 범위를 포함하며, 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다.
• public : 모든 곳에서 접근할 수 있다.

클래스와 접근 범위

• 클래스의 공개 API외의 모든 멤버는 private로 만들도록 한다.
• 오직 같은 패키지의 다른 클래스가 접근해야 하는 멤버에 한하여 package-private으로 풀어주도록 한다.
• 만약 권한을 풀어주는 일을 자주 하게 된다면 컴포넌트를 더 분해해야 하는 것은 아닌지 다시 고민해야 한다.
• private과 package-private 멤버는 모두 해당 클래스의 구현에 해당하므로 보통은 공개 API에 영향을 주지 않는다.
• 단, Serializable을 구현한 클래스에서 그 필드들도 의도치 않게 공개 API가 될 수 있다.

public 클래스와 protected

• public 클래스에서는 멤버의 접근 수준을 package-private에서 protected로 바꾸는 순간 그 멤버에 접근할 수 있는 대상 범위가 엄청나게 넓어진다.
• public 클래스의 protected 멤버는 공개 API이므로 영원히 지원돼야 한다.
• 또한 내부 동작 방식을 API 문서에 적어 사용자에게 공개해야 할 수도 있다. 따라서 protected 멤버의 수는 적을수록 좋다.

멤버 접근성 제약

• 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할 수 없다.
• 이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 한다는 규칙(리스코프 치환 원칙)을 지키기 위해 필요하다.
• 이 규칙을 어기면 하위 클래스를 컴파일할 때 컴파일 오류가 난다.
• 클래스가 인터페이스를 구현하는 건 이 규칙의 특별한 예로 볼 수 있고, 이때 클래스는 인터페이스가 정의한 모든 메서드를 public으로 선언해야 한다.

테스트와 접근 범위

• 테스트만을 위해 클래스, 인터페이스, 멤버를 공개 API로 만들어서는 안 된다.
• 테스트 코드를 테스트 대상과 같은 패키지에 두면 package-private 요소에 접근할 수 있다.

public 클래스와 인스턴스 필드

• public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.
• 필드가 가변 객체를 참조하거나, final이 아닌 인스턴스 필드를 public으로 선언하면 그 필드에 담을 수 있는 값을 제한할 힘을 잃게 된다.
• 그 필드와 관련된 모든 것들은 불변식을 보장할 수 없게 되며, 필드가 수정될 때 (락 획득 같은) 다른 작업을 할 수 없게 되므로 public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다.
• 이는 정적 필드에서도 마찬가지이지만, 해당 클래스가 표현하는 추상 개념을 완성하는 데 꼭 필요한 구성요소로써의 상수라면 public static final 필드로 공개해도 좋다.
  • 이런 필드는 반드시 기본 타입 값이나 불변 객체를 참조해야 한다.
  • 가변 객체를 참조하면 final이 아닌 필드에 적용되는 모든 불이익이 그대로 적용된다.
  • 다른 객체를 참조하지는 못하지만, 참조된 객체 자체는 수정될 수 있으므로 주의해야 한다.

배열

// 보안 허점이 숨어 있다.
public static final Thing[] VALUES = {...};

• 길이가 0인 배열은 모두 변경 가능하니 주의해야 한다. 따라서 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공하면 안 된다.

이에 대한 해결책은 두 가지다.

• 첫 번째 해결 방법은 public 배열을 private으로 만들고 public 불변 리스트를 추가하는 것이다.

private static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

• 두 번째 해결 방법은 배열을 private으로 만들고 그 복사본을 반환하는 public 메서드를 추가하는 방법이다(방어적 복사).

private static final Thing[] PRIVATE_VALUES = { ... };
public static final Thing[] values() {
    return PRIVATE_VALUES.clone();
}

자바 9에 추가된 모듈 시스템과 접근 수준

• 자바 9에서는 모듈 시스템이라는 개념이 도입되면서 두 가지 암묵적 접근 수준이 추가되었다.
• 패키지가 클래스들의 묶음이듯, 모듈은 패키지들의 묶음이다. 모듈은 자신에 속하는 패키지 중 공개(export)할 것들을 (관례상 module-info.java 파일에) 선언한다.
• protected 혹은 public 멤버라도 해당 패키지를 공개하지 않았다면 모듈 외부에서는 접근할 수 없다.
• 모듈 안에서는 exports로 선언했는지 여부에 아무런 영향도 받지 않는다.
• 모듈 시스템을 활용하면 클래스를 외부에 공개하지 않으면서도 같은 모듈을 이루는 패키지 사이에서는 자유롭게 공유할 수 있다.

... 자세한 내용은 나중에 필요할 때 책을 참고하자.

핵심 정리

프로그램 요소의 접근성은 가능한 한 최소한으로 하라. 꼭 필요한 것만 골라 최소한의 public API를 설계하자. 그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 해야 한다.
public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안 된다.
public static final 필드가 참조하는 객체가 불변인지 확인하라.