모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다.
정보 은닉(Information Hiding), 캡슐화(Encapsulation) -> 소프트웨어 설계의 근간
- 시스템
개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다. - 시스템
관리 비용을 낮춘다.각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적다. - 정보 은닉 자체가 성능을 높여주지는 않지만,
성능 최적화에 도움을 준다. 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화할 수 있기 때문 - 소프트웨어
재사용성을 높인다. 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않은 낯선 환경에서도 유용하게 쓰일 가능성이 크다. - 큰 시스템을 제작하는
난이도를 낮춰준다. 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.
접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성을 명시함으로써 정보 은닉을 위한 장치를 제공한다.
각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자(private, protected, public)으로 정해진다.
핵심은 접근제한자를 제대로 활용하는 것!
| 접근제한자 | 클래스 내부 | 동일 패키지 | 하위 클래스 | 그외의 영역 |
|---|---|---|---|---|
| public | O | O | O | O |
| protected | O | O | O | X |
| default | O | O | X | X |
| private | O | X | X | X |
접근 영역: public > protected > default > private
- 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다. 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해라.
- 공개 API를 세심히 설계한 후 그외의 모든 멤버는 private로 만든다.
- private과 package-private 멤버는 모두 해당클래스의 구현에 해당하므로 보통은 공개 API에 영향을 주지 않는다.
- public 클래스에서는 protected 멤버의 수는 적을수록 좋다.
- protected 멤버는 공개 API이므로 영원히 지원돼야 한다.
- public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.
- public 가변 필드를 갖는 클래스는 일반적으로 스레드에 안전하지 않다.
- 관례상 추상 개념의 상수라면 public static final 필드로 공개해도 좋다.
- 대신 기본 타입 값이나 불변 객체를 참조해야 한다.