어설프게 설계된 컴포넌트와 잘 설계된 컴포넌트의 가장 큰 차이는 바로 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐다. 잘 설계된 컴포넌트는 모든 내부 구현을 완벽히 숨겨, 구현과 API를 깔끔히 분리한다.
정보은닉, 혹은 캡슐화라고 하는 이 개념은 소프트웨어 설계의 근간이 되는 원리다.
정보은닉 장점의 대부분은 시스템을 구성하는 컴포넌트들을 서로 독립시켜서 개발, 테스트, 최적화, 적용, 분석, 수정을 개별적으로 할수 있게 해주는 것과 연관되어 있다.
[ 정보은닉의 장점 ]
- 시스템 개발 속도를 높인다. 여러 컴포넌트를 병렬로 개발할 수 있기 때문이다.
- 시스템 관리 비용을 낮춘다. 각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있다.
- 성능 최적화에 도움을 준다. 완성된 시스템을 프로파일링해 최적화할 컴포넌트를 정한 다음, 다른 컴포넌트에 영향을 주지 않고, 해당 컴포넌트만 최적화할 수 있기 때문이다.
- 재사용성을 높인다. 독자적으로 동작할 수 있는 컴포넌트라면 낯선 환경에서도 유용하게 쓰일 가능성이 크기 때문이다.
- 큰 시스템을 제작하는 난이도를 낮춰준다. 개별 컴포넌트의 동작을 검증할 수 있기 때문이다.
[ 접근 제어 메커니즘 ]
클래스, 인터페이스, 멤버의 접근성을 명시한다. 각 요소의 접근성은 그 요소가 선언된 위치와 접근 제한자(private, protected, public)로 정해진다.
private: 멤버를 서언한 톱레벨 클래스에서만 접근할 수 있다.
package-private: 멤버가 소속된 패키지 안의 모든 클래스에서 접근할 수 있다. 접근 제한자를 명시하지 않았을 때 적용되는 패키지 접근 수준이다.(단, 인터페이스의 멤버는 기본적으로 public이 적용된다.)
protected: package-private의 접근 범위를 포함하며, 이 멤버를 선언한 클래스의 하위 클래스에서도 접근할 수 있다.(제약이 따른다.)
public: 모든 곳에서 접근할 수 있다.
기본 원칙은 모든 클래스와 멤버의 접근성을 가능한 한 좁혀야 한다.
탑레벨 클래스와 인터페이스에 부여할 수 있는 접근 수준은 package-private과 public 두 가지다. public으로 선언하면 공개 API가 되며, package-private으로 선언하면 해당 패키지 안에서만 이용할 수 있다.
그런데 멤버 접근성을 좁히지 못하게 방해하는 제약이 하나 있다. 바로 상위 클래스의 메서드를 재정의할 때는 그 접근 수준을 상위 클래스에서보다 좁게 설정할 수 없다는 것이다. 이는 상위 클래스의 인스턴스는 하위 클래스의 인스턴스로 대체해 사용할 수 있어야 한다는 규칙(리스코프 치환 원칙)을 지키기 위해 필요하다.
public 클래스의 인스턴스 필드는 되도록 public이 아니어야 한다. 필드가 가변 객체를 참조하거나, final이 아닌 인스턴스 필드를 public으로 선언하면 그 필드에 담을 수 있는 값을 제한할 힘을 잃게 된다. public 가변 필드를 갖는 클래스는 일반적으로 스레드 안전하지 않다
이외에도 길이가 0이아닌 배열은 모두 변경 가능하니 주의하자. 따라서 클래스에서 public static final 배열 필드를 두거나 이 필드를 반환하는 접근자 메서드를 제공해서는 안된다. 이런 필드나 접근자를 제공한다면 클라이언트에서 그 배열의 내용을 수정할 수 있게 된다. 다음 코드에는 보안 허점이 존재한다.
public static final Thing[] VALUES = { ... };
어떤 IDE가 생성하는 접근자는 private 배열 필드의 참조를 반환하여 이같은 문제를 일으키니 주의하자. 해결책은 두가지며, 첫 번째 방법은 앞 코드의 public 배열을 private으로 만들고, public 불변 리스트를 추가하는 것이다.
private static final Thing[] PRIVATE_VALUES = { ... };
public static final List<Thing> VALUES =
Collections.unmodifiableList(Arrays.asList(PRIVATE_VALUES));
두 번째 배열을 private으로 만들고 그 복사본을 반환하는 public 메서드를 추가하는 방법이다.(방어적 복사)
private static final Thing[] PRIVATE_VALUES = { ... };
public static final Thing[] values() {
return PRIVATE_VALUES.clone();
}
클라이언트가 무엇을 원하느냐를 판단해 둘 중 하나를 선택하면 된다. 어느 반환 타입이 쓰기 편할지, 성능은 어느 쪽이 나을지를 고민해 정하자.
'Developer's_til > Effective Java' 카테고리의 다른 글
[item 18] 상속보다는 컴포지션을 사용하라 (0) | 2022.11.02 |
---|---|
[item 17] 변경 가능성을 최소화하라 (0) | 2022.11.01 |
[item 14] Comparable을 구현할지 고려하라 (0) | 2022.10.25 |
[item 13] 재정의는 주의해서 진행하라 (0) | 2022.10.24 |
[item 11] equals를 재정의하려거든 hashCode도 재정의하라 (0) | 2022.10.19 |