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

EFFECTIVE JAVA(이펙티브 자바)

 

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다.

---

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

잘 설계된 컴포넌트는 접근 권한을 잘 설정했는 지에 따라 달라진다. 

 

 

정보은닉

정보 은닉의 장점은 많지만 그 중 대부분은 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할 수 있게 해주는 것과 연관이 있다.

 

장점

• 시스템 개발 속도를 높인다. 
  여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.
• 시스템 관리 비용을 낮춘다.
   각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 부담도 적기 때문이다.
• 정보 은닉 자체가 성능을 높여 주지는 않지만, 성능 최적화에 도움을 준다.
• 소프트웨어 재사용성을 높인다.
  외부에 거의 의존하지 않고 독자적으로 동작할 수 있는 컴포넌트라면 그 컴포넌트와 함께 개발되지 않은 낯선 환경에서도 유용하게 쓰일 가능성이 크기 때문이다.
• 큰 시스템을 제작하는 난이도를 낮춰준다. 
  시스템 전체가 아직 완성되지 않은 상태에서도 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.

 

기본 원칙

모든 클래스와 멤버의 접근성을 가능한 한 좁혀야한다.

달리 말하면, 소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다는 뜻이다.

 

 

멤버에 부여할 수 있는 접근 수준

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

클래스의 공개 API를 세심히 설계한 후, 그 외의 모든 멤버는 private으로 만들자. 그런 다음 오직 같은 패키지의 다른 클래스가 접근해야 하는 멤버에 한하여 (private 제한자를 제거해) package-private으로 풀어주자.

권한을 풀어주는 일을 자주 하게 된다면 시스템에서 컴포넌트를 더 분해해야 하는 것은 아닌 지 고민해보자.

 

private과 package-private 멤버는 모두 해당 클래스의 구현에 해당하므로 보통은 공개 API에 영향을 주지 않지만, Serializable을 구현한 클래스에서는 그 필드들도 의도치 않게 공개 API가 될 수 있다.

 

그런데 멤버 접근성을 좁히지 못하게 방해하는 제약이 하나 있다. 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스 에서 보다 좁게 설정할 수 없다는 것이다. 이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 한다는 규칙(리스코프 치환 원칙)을 지키기 위해 필요하다.

 

 

public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다.

필드가 가변 객체를 참조하거나, final이 아닌 인스턴스 필드를 public으로 선언하면 그 필드에 담을 수 있는 값을 제한할 힘을 잃게 된다. (그 필드와 관련된 모든 것이 변경될 수 있다는 뜻)

public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다. 심지어 필드가 final이면서 불변 객체를 참조 하더라도 문제는 여전히 남는다. 내부 구현을 바꾸고 싶어도 그 public 필드를 없애는 방식으로는 리팩터링 할 수 없게 된다.

해당 클래스가 표현하는 추상 개념을 완성하는 데 꼭 필요한 구성요소로써의 상수라면 public static final 필드로 공개해도 좋다. 관례상 이런 상수의 이름은 대문자 알파벳과 _를 사용한다. 이런 필드는 반드시 기본 타입 값이나 불변 객체를 참조해야한다.

길이가 0이 아닌 배열은 모두 변경 가능하니 주의하자. 따라서 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안 된다. 이런 필드나 접근자를 제공한다면 클라이언트에서 그 배열의 내용을 수정할 수 있게 된다.

 

 

예시 1) 보안 허점이 존재하는 코드

 // 보안 허점이 숨어 있다. 
public static final Thing[] VALUES = { ... };

 

예시 2) 위의 보안 허점을 해결하는 방법 1 : 앞 코드의 public 배열을 private 으로 만들고 public 불변 리스트를 추가

private static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES =
    Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));

 

예시 2) 위의 보안 허점을 해결하는 방법 2 : 배열을 private으로 만들고 그 복사본을 반환하는 public 메서드 추가

private static final Thing[] PRIVATE_VALUES = { ... };
public static final Thing[] values)_ {
    return PRIVATE_VALUES.clone();
}

 

 

 

자바9 에서의 모듈 시스템

자바 9에서는 모듈 시스템이라는 개념이 도입되면서 두 가지 암묵적 접근 수준이 추가.

패키지가 클래스들의 묶음이듯, 모듈은 패키지들의 묶음

 

• 모듈은 자신에 속하는 패키지 중 공개(export)할 것들을(관례상 module-info.java 파일에) 선언
• protected / public 멤버라도 해당 패키지를 공개하지 않았다면, 모듈 외부에서 접근 불가능
• 모듈 안에서는 exports로 선언했는 지에 대해 영향을 받지 않음
• 모듈 시스템을 활용 시, 클래스를 외부에 공개하지 않으면서도 같은 모듈을 이루는 패키지사이에서는 자유롭게 공유 가능
• 앞서 다룬 4개의 기존 접근 수준과 달리, 모듈에 적용되는 새로운 두 접근 수준은 상당히 주의해서 사용
• 여러분 모듈의 JAR 파일을 자신의 모듈 경로가 아닌 애플리케이션의 클래스패스(classpath)에 두면 그 모듈 안의 모든 패키지는 마치 모듈이 없는 것처럼 행동
• 즉, 모듈이 공개 했는지 여부와 상관없이, public 클래스가 선언한 모든 public 혹은 protected 멤버를 모듈 밖에서도 접근할 수 있게 됨
• 새로 등장한 이 접근 수준을 적극 활용한 대표적인 예가 바로 JDK 자체다. 자바 라이브러리에서 공개하지 않은 패키지들은 해당 모듈 밖에서는 절대로 접근할 수 없다.

 

JDK 외에도 모듈 개념이 널리 받아들여질지 예측하기는 아직 이른 감이 있다. 그러니 꼭 필요한 경우가 아니라면 당분간은 사용하지 않는 게 좋을 것 같다.

 

 

 

• 정리

프로그램 요소의 접근성은 가능한 한 최소한으로 하자.

꼭 필요한 것만 골라 최소한의 public API를 설계하자. (public API는 계속 유지보수가 필요하기 때문)

그 외에는 클래스, 인터페이스, 멤버가 의도치 않게 API로 공개되는 일이 없도록 하자.

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

public static final 필드는 불변 객체만을 참조해야 한다.