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

[tonykang22]

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

핵심 정리 1: 구현과 API를 분리하는 "정보 은닉"의 장점

• 시스템 개발 속도를 높인다.
  • 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.
    • 만약 혼자 개발한다면, 해당 이점이 과연 이점으로 작용할지 고민이 될 수 있을 부분
• 시스템 관리 비용을 낮춘다.
  • 컴포넌트를 더 빨리 파악할 수 있기 때문이다.
    • 인터페이스 위주로 코드를 파악하면 더 빠르게 이해할 수 있고 디버깅 또한 쉽게 이뤄질 수 있다.
• 성능 최적화에 도움을 준다.
  • 프로파일링을 통해 최적화할 컴포넌트를 찾고 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 개선할 수 있기 때문이다.
    • 병목 구간을 파악하기가 용이하다. Ex. 어떤 모듈에서 병목이 일어나는지 쉽게 판단 가능
• 소프트웨어 재사용성을 높인다.
  • 독자적인 컴포넌트라면 해당
• 시스템 개발 난이도를 낮춘다.
  • 전체를 만들기 전에 개별 컴포넌트를 검증할 수 있기 때문이다.

핵심 정리 2: 클래스와 인터페이스의 접근 제한자 사용 원칙

• 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
• 톱레벨 클래스와 인터페이스에 package-private(default) 또는 public을 쓸 수 있다.
  • public으로 선언하면 API가 되므로 하위 호환성을 유지하려면 영원히 관리해야한다.
    • 변경이 발생한다면, 이를 사용하는 client의 코드도 모두 변경되어야한다.
    • 하위 버전 호환성을 제공하는 것은 장단점이 있는 문제이다.
      • 아무래도 자바가 하위 호환성을 존중하는 입장이다보니 사용하는 많은 API가 하위 호환성을 존중하는 경우이지 않을까
  • 패키지 외부에서 쓰지 않을 클래스나 인터페이스라면 package-private으로 선언한다.
• 한 클래스에서만 사용하는 package-private 클래스나 인터페이스는 해당 클래스에 private static으로 중첩시키자. (아이템 24)
  • 왜 저자는 private class가 아니라 private static class로 중첩시키자 했을까?
    • inner private class는 외부 인스턴스를 항상 참조한다.
      • inner private class의 필드로 외부 인스턴스를 갖는다.
    • 그러나 private static class는 inner 클래스이지만 아무런 reference가 없다.
      • 외부 인스턴스의 필드 등에 접근하지 못한다.
  • 그렇다면 왜 외부 인스턴스를 참조 하지 못하는 private static class가 더 어울린다는 것인가?
    • 애초에 둘 관계는 별개의 클래스 / 인터페이스 였기 때문에 서로의 관계가 없는 것이 올바른 관계 설정이다.

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

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