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 접근 제어자가 부여되면 안 됨