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

어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 차이점

• 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐의 차이.
• 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다.
• 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다.
• 정보 은닉 혹은 캡슐화는 소프트웨어 설계의 근간이 된다.

정보은닉의 장점

• 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.
  • 각 컴포넌트간 영향을 주지 않기 때문에 가능하다.
• 시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담이 적기 때문이다.
  • 특정 기능을 개선해야할 때 관련 컴포넌트만 분석하여 개선하면 되기 때문이다.
• 성능 최적화에 도움을 준다. 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정한 다음 다른 컴포넌트에 영향을 주지 않고 해당 컴포넌트만 최적화할 수 있기 때문이다.
  • 최적화시 특정 컴포넌트에만 집중해서 개선하면 되므로 최적화의 난이도가 낮아진다.
• 소프트웨어 재사용성을 높인다. 외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않은 낯선환경에서도 유용하게 쓰일 가능성이 크기 때문이다.
  • 말 그대로 독자적으로 동작하므로 모듈화하여 다른 시스템에서 활용할 수 있다.
• 큰 시스템을 제작하는 난이도를 낮춘다. 시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.
  • 유닛 테스트틀 통해 개별 컴포넌트의 정상 동작이 검증되므로 통합 테스트 간에 생길 수 있는 문제가 최소화된다.

정보은닉을 위한 장치

자바는 정보 은닉을 위한 다양한 장치를 제공하지만, 그중에서도 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)를 명시한다. 각 요소의 접근성은 그 요소가 선언된 접근 제한자로 정해진다.

기본 원칙은 모든 클래스와 멤버의 접근성은 가능한 한 좁혀야 한다. 달리 말하면, 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여 해야 한다.

접근 제한자의 종류

• private: 멤버를 선언한 톱레벨 클래스에서만 접근할 수 있다.
• package-private: 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 접근 제한자를 명시하지 않았을 때 적용되는 패키지 접근 수준이다.
• protected: package-private의 접근 범위를 포함하여 이 멤버를 선언한 클래스 하위 클래스(상속받은 클래스)에서도 접근할 수 있다.
• public: 모든 곳에서 접근할 수 있다.

클래스의 접근 제한자.

톱레벨 클래스(가장 바깥이란는 의미)와 인터페이스에 부여할 수 있는 접근 수준은 package-private과 public 두 가지다. public으로 선언하면 공개 API가 되고, package-private으로 선언하면 해당 패키지 안에서만 이용할 수 있다. package-private은 별도로 접근 제한자를 명시하지 않았을 때 부여되는 default 접근 지정자다.

패키지를 외부에서 쓸 이유가 없다면 package-private으로 선언하여 내부 구현을 통해 클라이언트(API를 참조하는 클래스) 가 아무런 피해 를 주지 않고 다음 릴리스에서 수정, 교체, 제거하자. 만약, public으로 선언한다면 API가 되므로 하위 호환을 위해 영원히 관리해줘야 한다.

접근 제한자의 주의사항

• 시스템 내 모든 클래스와 공유해야 하는 필드는 public 으로 하고 그 외에는 private으로 만든다.
• 오직 같은 패키지의 다른 클래스만 접근해야 할때는 private을 대신하여 default를 부여한다.
  • 이러한 일이 자주 일어 날 경우 클래스를 쪼갠다.
  • private 혹은 default인 필드는 public처럼 공개API는 아니지만 Serializable을 구현한 클래스에 속해있다면 공개 API될 수 있다.
• public 클래스에서는 멤버의 접근 수준을 default에서 protected로 바꾸는 순간 접근이 가능한 대상의 범위가 넓어지므로 신중하게 결정할 필요성이 있다.
• 접근 제한자는 한 번 지정되면 상속 받은 하위 클래스에서는 상위 클래스가 지정한 범위보다 좁게 바꿀 수 없다.
• 테스트 목적으로 private 필드를 default필드로 풀어줄 수는 있지만 완전히 public으로 만들어서는 안된다.

public Class 주의사항

• public class의 인스턴스 필드는 가급적 public이여서는 안된다. final이 아닌 인스턴스 필드를 public으로 하면 입력되는 값을 제한할 힘을 잃게 된다. 그 필드와 관련 불변식을 보장할 수 없게된다.
• 필드가 수정될 때 다른 작업을 할 수 없게 되므로 public 가변 필드를 갖는 클래스는 일반적으로 스레드가 안전하지 않다.
• public 접근 제한자 이면서 정적 필드로 선언해도 문제가 되지만 해당 클래스가 표현하는 추상 개념을 완성하는데 필요하면 public static final 로 공개해도되며, 이런 상수는 대문자 알파벳으로 하고 단어 사이에는(_) 를 넣는다. 그리고 반드시 불변 객체를 참조하도록 한다.불변성이 깨지는 순간 문제로 이어질 수 있다.

정적인 상수 배열 주의사항

public static final Object[] o 형태로 사용할 경우에는 주의해야 한다. 보기와 달리 상수가 아니고 삽입 삭제가 자유롭기 때문이다. 불변성을 지닐 줄 알고 사용했다가 도중에 변경되어서 문제로 이어질 수 있다. 이를 해결할 방법은 두가지다.

/* [code] 접근 제한자 public -> private 변경 & public 불변 리스트 추가 */
private static final Object[] PRIVATE_VALUE = {11,"이이",33};
public static final List<Object> VALUES=
        Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUE));

/* [code] 방어적 복사 */
private static final Object[] PRIVATE_VALUE = {11,"이이",33};
public static final Object[] values(){
    return PRIVATE_VALUE.clone();
}