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

• 잘 설계된 컴포넌트 → 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 잘 숨긴 컴포넌트 (구현과 API를 깔끔하게 분리)
• API를 통해서만 다른 컴포넌트와 소통하고 서로의 내부 동작 방식에는 참견하지 않음
• 정보 은닉과 캡슐화는 소프트웨어 설계의 근간이 되는 원리

 

정보 은닉

• 시스템 개발 속도를 높임 (여러 컴포넌트를 병렬로 개발할 수 있어서)
• 시스템 관리 비용을 낮춤. 컴포넌트를 빠르게 파악하여 디버깅이 가능하고, 다른 컴포넌트로 교체하는 부담도 적기 때문
• 최적화활 컴포넌트를 정한 다음, 다른 컴포넌트에 영향을 주지 않고 그것만 최적화 할 수 있어서 성능 최적화에 도움을 줌
• 소프트웨어 재사용성을 높임. 외부에 의존하지 않고 독자적으로 동작하는 컴포넌트는 다른 낯선 환경에서도 유용하게 쓰일 수 있음
• 시스템이 아직 완성되지 않았을 때 개별 컴포넌트의 동작을 검증할 수 있어서 제작 난이도를 낮춤
• 클래스, 인터페이스, 멤버의 접근성(선언 위치와 접근 제한자)을 명시함으로써 정보 은닉의 장치를 제공
• 모든 클래스와 멤버의 접근성을 가능한 좁혀야 함 (가능한 가장 낮은 접근 수준을 부여)

 

 

클래스의 접근 수준

• 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private(해당 패키지 안에서만 사용가능) 과 public(공개 api가 되어 하위 호환을 위해 영원히 관리해야함)
• public일 필요가 없는 클래스를 package-private 으로 좁히자.

 

 

멤버의 접근 수준

• 멤버에 부여할 수 있는 접근 수준은 private, package-private, protected, public
• private: 멤버를 선언한 톱레벨 클래스에만 접근 가능
• package-private(default): 패키지 안의 모든 클래스에서 접근 가능
• protected: 동일 패키지 및 상속받은 하위 클래스에서 접근 가능
• public: 모든 곳에서 접근 가능
• private과 package-private 멤버는 모두 해당 클래스의 구현에 해당하므로 공개 API에 영향을 주지 않는다.(Serializable 구현 클래스에서는 의도치 않게 공개 API가 될 수도있음)
• 상위 클래스의 메서드를 하위 클래스에서 재정의할때는 상위 클래스에서보다 좁게 설정할 수 없다. (리스코프 치환 원칙 - 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야함)
• public 클래스의 인스턴스 필드는 되도록 public이 아니어야함 (필드의 불변식을 보장 못하고 필드가 수정될때 다른 작업을 할 수 없으므로 스레드 안전하지 못함)
• 꼭 필요한 상수는 public static final 필드로 공개해도 좋음. (관례상 이름은 대문자 알파벳을 사용하고 단어 사이에 밑줄(_) 넣기). 반드시 기본타입 값이나 불변 객체를 참조해야함
• 배열을 public static final로 두거나 반환 접근 메서드를 제공해서는 안됨. 그럴경우 클라이언트가 수정가능

 

결론

접근성은 가능한 한 최소한으로 하고 꼭 필요한 것만 public API를 설계하자.

public 클래스는 상수용 public static final 필드 외에는 어떠한 public 필드도 가져가선 안됨.

public static final 필드가 참조하는 객체가 불변이어야함.