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

잘 설계된 컴포넌트 VS 어설프게 설계된 컴포넌트

차이점 : 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼는가 ??

잘 설계된 컴포넌트

• 모든 내부 구현을 완벽히 숨김
• 구현과 API를 깔끔히 분리

즉 오직 API를 통해서만 다른 컴포넌트와 소통하며 서로의 내부 동작 방식에는 전혀 개의치 않는다.

--> 정보 은닉, 캡슐화

WHY) 왜 정보 은닉을 해야하는가 ?

장점

1. 시스템 개발 속도를 높임
2. 시스템 관리 비용을 낮춤
3. 정보 은닉 자체가 성능을 높여주지는 않지만 성능 최적화에 도움을 줌
4. 소프트웨어 재 사용성을 높임
5. 큰 시스템을 제작하는 난이도를 낮춰줌

HOW) 어떻게 정보 은닉을 해야하는가 ?

우리는 자바에 대한 공부를 하고 있으니 자바에서는 어떻게 정보 은닉을 하는지 알아보자.

자바는 정보 은닉을 위한 다양한 장치를 제공함.

• 그 중 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)을 명시
• 각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자로 정해짐

접근 제한자를 제대로 활용하는 것이 정보 은닉의 핵심!

접근 제한자 종류

1. private : 멤버를 선언한 톱레벨 클래스에서만 접근 가능
2. package-private : 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있음

• 접근 제한자를 명시하지 않았을 때 적용되는 패키지 수준, 즉 default (단 interface의 멤버는 기본적으로 public)

3. protected : package-private의 접근 범위를 포함하며 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있음
4. public : 모든 곳에서 접근 가능

이러한 접근제한자를 제대로 활용하는 원칙에 대해 알아보자

접근 제한자 활용 원칙

• 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 함. (소프트웨어가 올바로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 함)

1. 톱레벨 클래스(가장 바깥이라는 의미)와 인터페이스에 부여할 수 있는 접근 수준은 package-private, public 두가지 이다.

• 톱레벨 클래스나 인터페이스를 public으로 선언하면 공개 API가 됨
• package-private로 선언하면 해당 패키지 안에서만 이용할 수 있음

패키지 외부에서 쓸 이유가 없다면 package-private로 선언하자

--> 그러면 API가 아닌 내부 구현이 되어 언제든 수정할 수 있음 (클라이언트에 아무런 피해 없이 수정, 교체, 제거 가능)

--> public으로 선언했더라면 API가 되므로 하위 호환을 위해 영원히 관리해줘야만 함..

2. 한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시키자 (아이템 24 참고)

• 톱레벨로 두면 같은 패키지의 모든 클래스가 접근할 수 있지만 private static으로 중첩시키면 바깥 클래스 하나에서만 접근할 수 있음

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

• 권한을 풀어주는 일을 자주 하게 된다면 해당 시스템에서 컴포넌트를 더 분해해야 하는 것이 아닌지 다시 고민 해봐야함.
• private와 package-private 멤버는 모두 해당 클래스의 구현에 해당하므로 보통은 공개 API에 영향을 주지 않음 (단 Serializable을 구현한 클래스에서는 그 필드들도 의도치 않게 공개 API가 될 수도 있음 --> 아이템 86, 87 참고)

4. protected 멤버의 수는 적을 수록 좋다.

• public 클래스에서는 멤버의 접근 수준을 package-private에서 protected로 바꾸는 순간 그 멤버에 접근할 수 있는 대상 범위가 엄청나게 넓어진다.
• public 클래스의 protected 멤버는 공개 API 이므로 영원히 지원돼야 함.
• 내부 동작 방식을 API 문서에 적어 사용자에게 공개해야 할 수도 있음 (아이템 19 참고)

5. 리스코프 치환 원칙(#26 참고) 을 지키기 위해 클래스가 인터페이스가 정의한 모든 메서드를 public으로 선언해야하는 제약(예외)이 존재한다.

• 위 원칙을 제대로 지키지 못하는 경우가 발생 즉 멤버 접근성을 좁히지 못하게 방해하는 제약이 있음
• 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할 수 없음
• 이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 하는 규칙인 리스코프 치환 원칙을 지키기 위해 필요
• 해당 규칙을 어길시 하위 클래스를 컴파일할 때 컴파일 오류가 발생
• 클래스가 인터페이스를 구현하는 건 이 규칙의 특별한 예
• 클래스는 인터페이스가 정의한 모든 메서드를 public으로 선언해야 함

6. 코드를 테스트하기 위한 목적으로 클래스, 인터페이스, 멤버의 접근 범위를 넓히진 말자 (적당한 수준까지는 괜찮음)

• 적당한 수준의 예로는 public 클래스의 private 멤버를 package-private 까지 풀어주는 것은 가능 (그 이상을 절대 안됨)
• 테스트 코드를 테스트 대상과 같은 패키지에 두면 package-private 요소에 접근 가능하기 때문
• 즉 테스트만을 위해 클래스, 인터페이스, 멤버를 공개 API로 만들어서는 안 된다.

7. public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다. (#39 참고)

• 필드가 가변 객체를 참조하거나 final이 아닌 인스턴스 필드를 public으로 선언하면 그 필드에 담을 수 없는 값을 제한할 힘을 잃게됨
• 해당 필드와 관련된 모든 것은 불변식으로 보장할 수 없다는 뜻
• 또한 필드가 수정될 때 (lock 획득 경우 등) 다른 작업을 할 수 없게 되므로 public 가변 필드를 갖는 클래스는 일반적으로 스레드에 안전하지 않음
• 필드에 final을 붙여 불변 객체를 참조하더라도 문제는 여전히 남음
• 내부 구현을 바꾸고 싶더라도 public 필드를 없애는 방식으로 refactoring 할 수 없게 되버림.

8. 7 의 예외가 존재 : 해당 클래스가 표현하는 추상 개념을 완성하는 데 꼭 필요한 구성요소로써의 상수라면 public static final 필드로 공개해도 됨.

• 7의 문제점은 정적 필드에서도 마찬가지
• 하지만 예외가 존재하는데 해당 클래스가 표현하는 추상 개념을 완성하는 데 꼭 필요한 구성요소로써의 상수인 경우 public static final 필드로 공개 가능
• 해당 상수의 표현 관례는 이름은 대문자 알파벳으로 쓰고 각 단어 사이에 밑줄(_)을 넣음 (아이템 68 참고)
• 또한 이러한 필드는 반드시 기본 타입 값이나 불변 객체를 참조 해야함 (아이템 17. 변경 가능성을 최소화하라 #37 참고)
• 가변 객체를 참조한다면 final이 아닌 필드에 적용되는 모든 불이익이 그대로 적용되기 때문
• 이러한 경우 다른 객체를 참조하지 못하지만 참조된 객체 자체는 수정될 수 있으니 끔찍한 결과를 초래할 가능성이 존재함

9. 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해선 안된다.

• 이런 필드나 접근자를 제공하면 클라이언트에서 그 배열의 내용을 수정할 수 있게 됨.

public static final Thing[] VALUES = {};

위의 코드는 보안에 허점이 존재함.
어떤 IDE가 생성하는 접근자는 private 배열 필드의 참조를 반환하여 이 같은 문제를 똑같이 일으키니 주의해야 함!

해결책

두 가지 해결 방법이 존재한다.

1. 앞 코드의 public 배열을 private로 바꾸고 public 불변 리스트를 추가하는 것

public static final List<Thing> VALUES = {};

Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));
// public static final List<Thing> VALUES = List.of(PRIVATE_VALUES);
// List.of() 또한 불변 리스트를 반환함

2. 배열을 private로 만들고 그 복사본을 반환하는 public 메서드를 추가하는 방법 (방어적 복사)

private static final Thing[] PRIVATE_VALUES = {};

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

• 클라이언트가 무엇을 원하느냐에 따라 위 둘 중 하나를 선택하면 됨
• 어느 반환 타입이 더 쓰기 편할지, 성능은 어느 쪽이 좋을지 고민해서 정하면 된다

모듈 시스템

JAVA 9 부터 모듈 시스템이라는 개념이 도입되면서 두 가지 암묵적 접근 수준이 추가됨

모듈 : 패키지 묶음

• 자신에 속한 패키지 중 공개 (export) 할 것들을 선언 (관례상 module-info.java 파일에 선언)

암묵적 접근 수준 : public, protected 수준의 효과가 모듈 내부로 한정

• protected 혹은 public 멤버라도 해당 패키지를 공개하지 않았다면 모듈 외부에서는 접근할 수 없다
• 물론 모듈 안에서는 exports로 선언했는지 여부에 아무런 영항도 받지 않음.
• 모듈 시스템을 활용하면 클래스 외부에 공개하지 않으면서도 같은 모듈을 이루는 패키지 사이에서는 자유롭게 공유 가능.

두가지 암묵적 접근 수준

• 숨겨진 패키지 안에 있는 public 클래스의 public 혹은 protected 멤버와 관련
• 해당 암묵적 접근 수준들은 각각 public 수준과 protected 수준과 같으나 그 효과가 모듈 내부로 한정되는 변종
• 이러한 형태로 공유해야하는 상황은 흔치 않음
• 만약 이런 상황이 발생하더라도 패키지들 사이에서 클래스들을 재배치 하면 대부분 해결됨

두가지 암묵적 접근 수준의 주의 사항

• 이전에 설명한 기존 접근 수준 (public ,package-private, protected, private)와 달리 새로운 두가지 암묵적 접근 수준은 상당히 주의해서 사용해야 함
• 모듈의 JAR 파일을 자신의 모듈 경로가 아닌 애플리케이션의 클래스패스 (classpath)에 두면 그 모듈 안의 모든 패키지는 마치 모듈이 없는 것처럼 행동
• 즉 모듈이 공개했는지 여부와 상관없이 public 클래스가 선언한 모든 public 혹은 protected 멤버를 모듈 밖에서도 접근할 수 있음

모듈 시스템의 활용

• 새로 등장한 해당 암묵적 접근 수준은 JDK에서 적극 활용 했음
• 자바 라이브러리에서 공개하지 않은 패키지들은 해당 모듈 밖에서는 절대 접근할 수 없음

ETC

• 접근 보호 방식이 추가된 것 말고도 모듈은 여러 면에서 자바 프로그래밍에 영향을 끼쳤음

모듈의 장점을 활용하는 법

• 패키지들을 모듈 단위로 묶고 모듈 선언에 패키지들의 모든 의존성을 명시
• 소스 트리를 재배치하고 모듈 안으로부터 (모듈 시스템을 적용하지 않는) 일반 패키지로의 모든 접근에 특별한 조치를 취함

모듈 시스템의 현재

• JDK 외에도 모듈 개념이 널리 받아들여질지 아직 예측하기 이른 감이 있음.
• 따라서 꼭 필요한 경우가 아니라면... 당분간은 사용은 자제

정리

컴포넌트를 잘 설계하기 위해선 -> 정보 은닉, 캡슐화

정보은닉을 위한 접근 제한자를 잘 활용하자 -> 접근 제한자 활용 원칙

모듈 시스템이라는 것도 있다