Item 15 - 클래스와 멤버의 접근 권한을 최소화하라

구현과 API를 분리하는 “정보 은닉”의 장점

• 시스템 개발 속도를 높인다. (여러 컴포넌트를 병렬로 개발할 수 있기 때문에)
• 시스템 관리 비용을 낮춘다. (컴퍼넌트를 더 빨리 파악할 수 있기 때문에)
• 성능 최적화에 도움을 준다. (최적화할 컴포넌트를 정한 후, 다른 컴포넌트에 영향끼치지 않고 해당 컴포넌트만 개선 가능하기 때문에)
• 소프트웨어 재사용성을 높인다. (외부에 의존하지 않는 독자적인 컴포넌트라면)
• 시스템 개발 난이도를 낮춘다. (전체를 만들기 전에 개별 컴포넌트를 검증할 수 있기 때문에)

클래스와 인터페이스의 접근 제한자 사용 원칙

• 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
• 톱레벨 클래스와 인터페이스에 package-private 또는 public을 쓸 수 있다.
• public으로 선언하면 API가 되므로 하위 호환성을 유지하려면 영원히 관리해야 한다.
• 패키지 외부에서 쓰지 않을 클래스나 인터페이스라면 package-private으로 선언한다.
• 한 클래스에서만 사용하는 package-private 클래스나 인터페이스는 해당 클래스에 private static으로 중첩 시키자. (아이템 24)

멤버(필드, 메서드, 중첩 클래스/인터페이스)의 접근 제한자 원칙

• private과 package-private은 내부 구현.
• public 클래스의 protected와 public은 공개 API.
• 코드를 테스트 하는 목적으로 private을 package-private으로 풀어주는 것은 허용할 수 있다.
  • 하지만 테스트만을 위해서 멤버를 공개 API로 만들어서는 안된다.
  • 테스트를 같은 패키지에 만든다면 그럴 필요도 없다.
• public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.
  • 필드의 불변식을 보장하지 못한다.
  • 필드가 수정될 때 다른 작업을 할 수 없으므로 스레드 안전하지 못하다. (아이템 16)
• 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공하지 말자.

💡 핵심 정리

• 프로그램 요소의 접근성은 가능한 한 최소한으로 하고, 꼭 필요한 것만 public API로 설계하자.
• public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져선 안된다.
• public static final 필드가 참조하는 객체는 불변이어야 한다.