클래스와 멤버의 접근 권한을 최소화하라
잘 구현된 컴포넌트의 조건은 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리하는 것이다. 오직 API로만 통신을 해 내부 동작 방식에는 개의치 않게 하는 것이다. 이것이 바로 캡슐화의 개념이다.
캡슐화의 장점은 다음과 같다.
- 여러 컴포넌트를 병렬로 개발해 시스템 개발 속도를 높인다.
- 각 컴포넌트를 더 빨리 파악하여 디버깅하고 컴포넌트 교체 비용을 낮춰 시스템 관리 비용을 낮출 수 있다.
- 성능 최적화에 도움을 준다.
- 소프트웨어 재사용성을 높인다. 독립성이 보장된 컴포넌트는 낯선 환경에서도 유용하게 쓰일 수 있다.
- 시스템 전체가 완성되지 않아도 개별 컴포넌트의 동작을 검증할 수 있어 큰 시스템을 제작하는 난이도를 낮춰준다.
자바는 정보 은닉을 위한 다양한 장치를 제공한다. 그 중 접근 제어 메커니즘은 클래스, 인터페이스, 멤버의 접근성(접근 허용 범위)를 명시한다. 각 요소의 접근성은 접근 제한자(private, protected, public) 로 정해진다. 핵심은 모든 클래스와 멤버의 접근성을 접근제한자를 이용해 가능한 좁혀야 하는 것이다. 달리 말하면 소프트웨어가 올바르게 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 한다는 뜻이다.
(가장 바깥이라는 의미의) 톱 레벨 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private과 public 두 가지이다. 톱 레벨 클래스나 인터페이스를 publi으로 선언하면 공개 API가 되고, package-private으로 선언하면 해당 패키지 안에서만 사용할 수 있다. package-private을 사용하면 API가 아닌 내부구현이 되어 언제든 수정할 수 있다. 클라이언트에 아무런 피해 없이 다음 릴리즈에서 수정, 교체, 제거를 할 수 있다. 하지만 public으로 선언 시 API가 되기 때문에 하위호환을 위해 영원히 관리해줘야한다.
만약 package-private으로 선언된 최상위 레벨 클래스나 인터페이스를 사용하는 클래스가 하나뿐이라면, 해당 최상위 레벨 클래스를 사용자 클래스의 private static 클래스로 중첩 시켜라. 이렇게 만들면 패키지 전체가 아니라 단 하나의 클래스만이 해당 클래스에 접근할 수 있다.
멤버(필드, 메서드, 중첩 클래스, 중첩 인터페이스)에 부여할 수 있는 접근 수준
- private : 멤버를 선언한 톱레벨 클래스에서만 접근할 수 있다.
- package-private : 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. default 접근 수준이다.(단, 인터페이스의 멤버는 public이 default)
- protected : package-private의 접근 범위를 포함하며, 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다.
- public : 모든 곳에서 접근할 수 있다.
- 공개 API를 세심히 설계한 후, 그 외의 모든 멤버는 private으로 만들어라
- 그 다음 오직 같은 패키지의 다른 클래스가 접근해야하는 멤버에만 package-private으로 풀어주어라.
- 이 때 권한을 풀어주면서 시스템에서 컴포넌트를 더 분해해야 하는 것은 아닌지 고민해보자.
private과 package-private 멤버는 해당 클래스의 구현에 해당하기 때문에 공개API에 영향을 주지 않는다. 하지만, Serializable을 구현한 클래스에서는 그 필드들도 의도치 않게 공개 API가 될 가능성이 있다.
public 클래스에서는 멤버의 접근 수준을 package-private -> protected로 변경 시 접근할 수 있는 대상 범위가 넓어진다. public 클래스의 protected 멤버는 공개 API이기 때문에 영원히 지원해야 한다. 또, 내부 동작 방식을 API에 적어 사용자에게 공개해야한다.그래서 protected 멤버는 적을수록 좋다.
한계점
멤버 접근성을 항상 좁힐 수 있는 것은 아니다. 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할 수 없다. 이 제약은 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야한다는 리스코프 치환 원칙 때문이다. 이를 어기면 컴파일 오류가 날 것이다. 클래스가 인터페이스를 구현하는 것은 이 규칙의 특별한 예로 볼 수도 있고, 이 때 클래스는 인터페이스가 정의한 모든 메서드를 public으로 선언해야한다.
테스트 시 클래스, 인터페이스, 멤버의 접근 범위를 넓히려할 때가 있다. 예를 들어, 클래스의 private 멤버를 package-private으로 풀 순있지만 그 이상은 안된다. 적당한 선까지만 가능하다. 즉, 테스트만을 위해 공개 API로 만들어서는 안된다는 것이다.
public 클래스의 인스턴스 필드는 public이 되면 안 된다.
필드가 가변 객체를 참조하거나 final이 아닌 인스턴스 필드를 public으로 선언하면 그 필드에 담을 수 있는 값을 제한할 힘을 잃게 된다. 외부에 의해 맘대로 바뀔 수 있다는 것이다. 또, 필드가 수정될 때 (락 획득 같은) 다른 작업을 할 수 없기 때문에 public 가변 필드를 가진 클래스는 스레드 안전하지 않다. 필드가 final이면서 불변 객체를 참조하더라도 마찬가지다. 내부 구현을 바꾸고 싶어도 public 필드를 없애는 방식으로는 리팩토링 할 수 없게된다.
이는 정적 필드에서도 마찬가지지만 예외가 하나 있다. 해당 클래스가 표현하는 추상 개념을 완성하는데 꼭 필요한 구성요소의 상수라면 public static final로 공개해도 좋다. 관례상 대문자 형태의 변수 이름을 갖고 단어 사이에 밑줄('_')을 넣는다. 이런 필드는 반드시 기본 타입 값이나 불변 객체를 참조해야한다. 가변객체를 참조한다면 그 필드에 적용되는 모든 변화가 그대로 동기화된다.
길이가 0이 아닌 배열은 모두 변경 가능하니 주의하자. 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 두어서는 안된다.
public static final Thing[] VALUES = {...}; // 보안 허점위와 같은 경우는 누구나 접근할 수 있기 때문에 배열의 내용을 수정할 수 있게된다.
어떤 IDE가 생성하는 접근자는 private 배열 필드의 참조를 반환하여 이 같은 문제를 똑같이 일으키니 주의하자. ???
해결책은 다음과 같다.
- public 배열을 private으로 만들고, public 불변 리스트를 추가한다.
- 배열을 private으로 만들고 그 복사본을 반환하는 public 메서드를 추가한다.
// 첫 번째 방법
private static final Thing[] PRIVATE_VALUES = {...};
public static final List<Thing> VALUES = Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));// 두 번째 방법
private static final Thing[] PRIVATE_VALUES = {...};
public static final Thins[] values() { return PRIVATE_VALUES.clone(); }클라이언트가 무엇을 원하냐에 따라 사용하면 된다.
자바9 모듈 추후 기술 필요
