잘 설계된 컴포넌트는 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 잘 숨겨둔 컴포넌트이다. 즉, 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔하게 분리한다. 오직 API를 통해서 다른 컴포넌트와 소통하고, 서로의 내부 동작 방식에는 관여하지 않아야한다. 이 개념이 바로 객체지향의 핵심인 캡슐화의 원리이다.
캡슐화(정보 은닉)의 장점을 요약하자면 다음과 같다 - 1) 시스템을 구성하는 컴포넌트들을 서로 독립시키어, 2) 개발, 테스트, 최적화, 적용, 분석, 수정 을 개별적으로 가능하게 한다.
구체적인 장점들은 다음과 같다.
여러 컴포넌트를 병렬로 개발할 수 있기 때문에 개발 속도가 빨라진다.
각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적지 않기 때문이다.
캡슐화 자체가 성능을 높히진 않지만, 성능 최적화엔 도움을 준다. 완성된 시스템을 프로파일링하여 최적화할 컴포넌트를 정한 뒤, 다른 커포넌트에 영향을 주지않고, 해당 컴포먼트만 최적화할 수 있기 때문이다.
외부에 거의 의존하지 않고, 독자적으로 동작할 수 있는 컴포넌트라면, 그 컴포넌트와 함께 개발되지 않은 낯선 환경에서도 유용하게 쓰일 가능성이 크다.
시스템 전체가 완성되지 않아도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.
모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
캡슐화의 핵심은 접근 제한자를 올바르게 활용하는 데에 있다.
톱레벨 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private, public 두 가지 이다. 톱레벨 클래스나 인터페이스를 public으로 선언하면 공개 API가 되고, package-private으로 선언하면 해당 패키지 안에서만 이용할 수 있다. 패키지 외부에서 쓸 이유가 없다면 package-private으로 선언하는 것이 좋은데, 내부 구현이기 때문에 언제든 수정이 가능하다. 즉 클라이언트에 아무런 피해없이 다음 릴리즈에서 수정이나 교체, 삭제가 가능하다. 하지만 public으로 선언한 경우엔 API가 되기 때문에 하위 호환을 위해 영원히 관리해주어야 한다.
public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다. public static final로 선언된 상수 외엔 모든 필드는 private 해야한다. public 가변 필드를 갖는 클래스는 일반적으로 스레드에 unsafe 하다.