15. 클래스와 맴버의 접근 권한을 최소화하라

어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를

외부 컴포넌트로부터 얼마나 잘 숨겼느냐다

- 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다

- 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다.

- 정보 은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다.

---

정보 은닉의 장점은 정말 많다 그중 대부분은 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화

적용, 분석, 수정을 개별적으로 할수 있게 해주는것과 연관 되어 있다

* 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다

* 시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적기 때문이다

* 정보 은닉 자체가 성능을 높여주지는 않지만, 성능 최적화에 도움을 준다.
   완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정한 다음 다른 컴포넌트에 영향을 주지않고 해당 컴포넌트만 최적화

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

* 큰 시스템을 제작하는 난이도를 낮춰준다. 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증

- 자바는 정보 은닉을 위한 다양한 장치를 제공한다

- 그중 접근 제어 메커니즘은 클래스, 인터페이스, 맴버의 접근성을 명시한다

- 각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자로 정해진다

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

 

모든 클래스와 맴버의 접근성을 가능한 한 좁혀야 한다

---

톱레벨 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private 과 public 두가지다

- 톱레벨 클래스나 인터페이스를 public으로 선언하면 공개 API가 되며, package-private으로 선언하면 해당 패키지 안에서만 이용

- 패키지 외부에서 쓸 이유가 없다면 package-private으로 선언하자

- 그러면 이들은 API가 아닌 내부 구현이 되어 언제든 수정할 수 있다.

- 즉, 클라이언트에 아무런 피해없이 다음 릴리스에서 수정, 교체, 제거할 수 있다

- 반면, public 으로 선언한다면 API가 되므로 하위 호환을 위해 영원히 관리해줘야만 한다.

---

한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는

클래스 안에 private static으로 중첩시켜보자

- 톱레벨로 두면 같은 피키지의 모든 클래스가 접근할수 있지만, private static으로 중첩시키면 바깥 클래스 하나에만 접근할수 있다

- public일 필요가 없는 클래스의 접근 수준을 package-private 톱레벨 클래스로 좁히는 일

- public 클래스는 그 패키지의 API인 반면, package-private 톱레벨 클래스는 내부구현에 속하기 때문이다

---

맴버에 부여할 수 있는 접근 수준은 4가지 이다

* private : 맴버를 선언한 톱레벨 클래스에서만 접근할 수 있다.

* package-private : 맴버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 접근 제한자를 명시하지 않았을때 적용되는 패키지 접근 수준이다(단, 인터페이스의 맴버는 기본적으로 public이 적용된다)

* protected : package-private의 접근 범위를 포함하며, 이 맴버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다

* public : 모든 곳에서 접근할수 있다

---

클래스의 공개 API를 세심히 설계한 후, 그 외의 모든 맴버는 private으로 만들자. 그런 당므 오직 같은 패키지의 

다른 클래스가 접근해야 하는 맴버에 한하여 package-private으로 풀어주자

- 권한을 풀어주는 일을 자주 하게 된다면 여러분 시스템에서 컴포넌트를 더 분해해야 하는것은 아닌지 다시 고민해보자

- private과 package-private 맴버는 모두 해당 클래스의 구현에 해당하므로 보통은 공개 API에 영향을 주지 않는다

- 단, Serializable을 구현한 클래스에서는 그 필드들도 의도치 않게 공개 API가 될 수도 있다

---

public 클래스에서는 맴버의 접근 수준을 package-private에서 protected로 바꾸는 순간 

그 맴버에 접근할 수 있는 대상 범위가 엄청나게 넓어 진다

- public클래스의 protected 맴버는 공개 API 이므로 영원히 지원돼야 한다

- 또한 내부 동작 방식을 API 문서에 적어 사용자에게 공개해야 할 수도 있다 따라서 protected 맴버의 수는 적을수록 좋다

---

그런데 맴버 접근성을 좁히지 못하게 방해하는 제약이 하나 있다

- 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할수 없다는 것이다

- 이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 한다는 규칙을 지키기 위해 필요하다

- 이 규칙을 어기면 하위 클래스를 컴파일 할때 컴파일 오류가 난다

- 클래스가 인터페이스를 구현하는 건 이 규칙의 특별한 예로 볼수 있고, 이때 클래스는 인터페이스가 정의한 모든 메서들를 public 선언

---