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

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

👾 캡슐화 : 소프트웨어 설계의 근간이 되는 원리

• 잘 설계된 컴포넌트
  -> 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리함
• 오지 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않음

캡슐화의 장점?

• 시스템 개발 속도를 높인다.
  -> 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.
• 시스템 관리 비용을 낮춘다.
  -> 각 컴포넌트를 더 빨리 파악하여 디버깅 할 수 있고, 다른 컴포넌트로 교체하는 부담도 적다.
• 성능 최적화에 도움을 준다.
  -> 최적화할 컴포넌트를 정한 다음 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화 가능
• 소프트웨어 재사용성을 높임
  -> 외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 낯선 환경에서도 유용하게 쓰일 가능성이 크다.
• 큰 시스템을 제작하는 난이도를 낮춰준다.
  -> 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있다.

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

접근 제한자 ?

• private : 멤버를 선언한 톱레벨 클래스에서만 접근 가능
• package-private : 멤버가 소속된 패키지 안의 모든 클래스에서 접근 가능
• protected :멤버를 선언한 클래스의 하위클래스에서도 접근할 수 있다.
• public : 모든 곳에서 접근 가능

🐻 기본 원칙 : 모든 클래스와 멤버의 접근성을 가능한 한 좁혀라 !

톱레벨 클래스와 인터페이스 -> package-private, public

• 패키지 외부에서 사용할 이유가 없다면 package-private로 선언하자
  -> API가 아닌 내부 구현이 되어 언제든 수정할 수 있다.
  -> 클라이언트에 아무런 피해 없이 다음 릴리스에서 수정, 교체, 제거할 수 있다.
• 한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩 시켜보자
  -> 바깥 클래스 하나에서만 접근할 수 있다.
• public일 필요가 없는 클래스의 접근 수준을 package-private 톱레벨 클래스로 좁히자
  -> public 클래스는 크 패키지의 API인 반면, package-private 톱레벨 크래스는 내부 구현이기 때문

멤버(필드, 메서드, 중첩 클래스, 중첩 인터페이스) -> 4가지 다

• 클래스의 공개 API를 설계 후 그 외의 모든 멤버는 private로 만들고, 오직 같은 패키지의 다른 클래스가 접근해야하는 멤버에 한하여 package-private로 만들자
  -> 권한을 풀어주는 일을 자주 하게 된다면 컴포넌트를 더 분해해야하는것은 아닌지 고민해보자
• public 클래스의 인스턴스 필드는 되도록 public이 아니어야한다.
  -> public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다.