어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐(정보 은닉, 캡슐화)이다.
정보 은닉의 장점은 다음과 같다.
- 시스템 개발 속도를 높인다
- 여러 컴포넌트를 병렬로 개발 가능
- 시스템 관리 비용을 낮춘다
- 각 컴포넌트를 더 빨리 파악하고, 디버깅 가능
- 다른 컴포넌트로 교체하는 부담이 적음
- 성능 최적화에 도움을 준다
- 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화 가능
- 소프트웨어 재사용성을 높인다
- 외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트는 낯선 환경에서도 유용하게 쓰일 가능성이 큼
- 큰 시스템을 제작하는 난이도를 낮춰준다
- 개발중에도 개별 컴포넌트의 동작을 검증할 수 있음
기본 원칙 : 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
- 톱 레벨 클래스와 인터페이스에는
public과package-private만 부여할 수 있다- public으로 선언하면 공개 API가 되어 하위 호환을 위해 영원히 관리해줘야 한다
- package-private로 선언하면 해당 패키지 안에서만 사용할 수 있다
- 외부에서 쓸 이유가 없다면 package-private로 선언하여 내부구현으로 만들자
- 한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시키자
- public, protected, package-private, private 모두 부여할 수 있다
| 해당 클래스 안에서 접근 가능? | 같은 패키지 안에서 접근 가능? | 상속받은 클래스에서 접근 가능? | 외부에서 접근 가능? | |
|---|---|---|---|---|
| public | O | O | O | O |
| protected | O | O | O | X |
| package-private | O | O | X | X |
| private | O | X | X | X |
protected 멤버 수는 적을수록 좋다
- package-private에서 protected로 변경하는 순간 접근할 수 있는 대상 범위가 넓어진다
테스트만을 위해 클래스, 인터페이스, 멤버를 공개 API로 만들면 안된다
public클래스의 인스턴스 필드는 상수가 아니라면 되도록 public이 아니여야 한다
클래스에 길이가 0이 아닌 public static final배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공하면 안된다
- 배열의 내용이 수정될 수 있다
꼭 필요한 것만 골라 최소한의 public API를 설계하자. public 클래스는 상수(불변) 외에는 public필드를 가지면 안된다.