Item 15. 클래스와 멤버의 접근 권한을 최소화하라
잘 설계된 컴포넌트
잘 설계된 컴포넌트라면
외부로부터 내부 구현을 완벽히 숨겨야함이를
정보 은닉(캡슐화)라고 부름
외부에서는 단순히 API를 호출해 원하는 동작만을 수행하고, 내부 구현이 어떻게 되어 있는지는 알 필요가 없도록 해야 함
그래야 내부 구현이 변경되어도 외부에 영향을 주지 않을 수 있음
정보 은닉의 장점
정보 은닉의 장점은 은닉된 부분은 변경되어도 외부에 영향을 주지 않으므로 컴포넌트 간 독립을 통해 개발을 병렬화하고, 테스트 코드, 최적화 등의 작업을 개별적으로 수행할 수 있다는 것
컴포넌트가
병렬적으로 개발되므로개발 속도를 높일 수 있음테스트, 최적화 등이
개별적으로 수행되므로효율적
또한, 내부 역시 외부에 의존하지 않으므로 컴포넌트의
재사용성을 높일 수 있음내부가 제대로 구현되지 않은 상태에서도 외부 코드를 작성하는 것이 가능
단순히 API를 호출하는 것뿐이므로, 그렇게 코드를 작성하면 됨
API 내부가 미구현 상태라고 하더라도, API가 원하는 결과를 반환한다고 가정한 mock 테스트 등을 통해 외부 컴포넌트의 동작을 검증하는 것이 가능
정보 은닉의 핵심은 접근 제어자를 잘 활용하는 것
정보 은닉의 기본 원칙은 모든 클래스의 멤버의 접근성을 최소화하는 것
필드는 크게 외부에서 API처럼 여기는 것과 외부에서 존재조차 인지하지 못하는 것으로 분리
public, protected 접근 제어자를 갖는 경우 공개 API로 취급됨
public은 직접 호출해 사용이 가능하므로 당연한 것이고, protected는 이를 상속하는 하위 클래스를 만들 수 있기 때문
package, private 접근 제어자를 갖는 경우 패키지 외부에서는 사용할 수 없으므로 외부에서는 이들의 존재조차 모르며, 내부 구현이 수정되어도 문제가 없음
이와 달리 API는 다른 동작을 하도록 변경되지 않아야 함은 물론, 항상 하위 호환을 관리해야 함
따라서,
private을 package로 바꾸는 것까지는 괜찮지만 그보다 넓은 범위의 접근을 허용하고자 한다면 매우 심사숙고해야 함
public 클래스의 필드는 public이 아니어야 함
public 가변(non-final) 필드의 문제점
public 가변 필드는 외부에서 이 필드의 값을 수정할 수 있음
이는 이 필드와 관련된 모든 것은 불변을 보장할 수 없음을 의미
또한, 스레드 안정성을 보장할 수도 없음
하지만 그렇다고 해서 이 필드를 불변으로 만든다고 문제가 해결되는 것은 아님
public 불변(final) 필드의 문제점
필드가 불변이라 해도 할당되는 객체가 가변인 경우 객체 내부 값이 변경될 수 있는 위험은 여전히 존재
이 문제 때문에 절대로 배열 필드에는 public 접근 제어자를 적용하거나 접근자 메서드를 제공하면 안 됨
불변으로 선언하는 경우에도, 어쨌든 접근 제어자가 public이라 이 필드는 API이므로 내부 구현을 바꾸는 것이 불가능
public이 허용되는 필드
이 필드가 해당 클래스가 표현하는 추상 개념의 구성 요소에 해당하는
상수인 경우ex) 앞선 Item 14에서 봤던 String 클래스의
CASE_INSENSITIVE_ORDER필드가 이에 해당// 문자열을 비교하는 방법 중 한 가지를 나타내는 상수 필드 public static final Comparator<String> CASE_INSENSITIVE_ORDER = new CaseInsensitiveComparator();
이 경우 필드명을 모두 대문자로 작성하고 단어 사이는 언더바(_)로 연결하는 것이 관례
즉, 상수처럼 동작하는
불변 객체를 참조하는 static final 필드가 아니고서야public접근 제어자가 부여되면 안 됨
Last updated