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

JAVA · 16 Apr 2023

시스템 개발 속도를 높인다.
- 여러 컴포넌트를 병렬로 개발할 수 있기 때문에
시스템 관리 비용을 낮춘다.
- 컴포넌트를 더 빨리 파악할 수 있기 때문에
성능 최적화에 도움을 준다.
- 프로파일링을 통해 최적화할 컴포넌트를 찾고 다른 컴포넌트에 영향을 주지 않고
  해당 컴포넌트만 개선할 수 있기 때문에
소프트웨어 재사용성을 높인다.
- 독자적인 컴포넌트라면
시스템 개발 난이도를 낮춘다.
- 전체를 만들기 전에 개별 컴포넌트를 검증할 수 있기 때문

접근 제한자를 제대로 활용하는 것이 정보 은닉의 핵심이다.

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

모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
(가장 바깥이라는 의미의) 톱레벨 클래스와 인터페이스에 package-private(default) 또는 public을 쓸 수 있다.
- public으로 선언하면 API가 되므로 하위 호환성을 유지하려면 영원히 관리해야 한다.
- 패키지 외부에서 쓰지 않을 클래스나 인터페이스라면 package-private(default)으로 선언한다.
  - 그러면 API가 아닌 내부 구현(클라이언트와 상관없음)이 되어 언제든지 수정할 수 있다.
한 클래스에서만 사용하는 package-private(default) 클래스나 인터페이스는 해당 클래스에 private static으로 중첩 시키자.
- private인 inner class는 상위레벨 클래스를 참조하고 있어, 분리되지 않는다.
- private static인 inner class는 상위레벨 클래스와 독립적으로 사용된다.

private과 package-private은 내부 구현
public 클래스의 protected와 public은 공개 API
코드를 테스트 하는 목적으로 private을 package-private으로 풀어주는 것은 허용할 수 있다.
하지만 테스트만을 위해서 멤버를 공개 API로 만들어서는 안된다.
- 테스트를 같은 패키지에 만든다면 그럴 필요도 없다.
public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.
- 상수용 public static final 필드 외에는 어떠한 public 필드도 가져서는 안된다.
클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근 메서드를 제공해서는 안된다.
- 이런 필드나 접근자를 제공한다면 클라이언트에서 그 배열의 내용을 수정할 수 있게 된다.
- public static final 필드가 참조하는 객체가 불변인지 확인해라.