필드를 노출하면 캡슐화가 깨진다
public 클래스에는 절대 가변 필드를 직접 노출해서는 안된다. (불변 필드도 안심할 수 없다.)
하지만 package-private 클래스나 private 중첩 클래스에서는 종종 필드를 필드를 노출하는 편이 나을 때도 있다.
일단 public 클래스에서 데이터 필드에 직접 접근한다면 캡슐화가 깨지는 것이다(Item15). 그렇게 되면 단점이 많은데, 불변식을 보장할 수도 없고, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다.
그래서 필드는 모두 private으로 바꾸고, 접근자(getter) 및 변경자(mutator, setter)를 두는 방식으로 개선할 수 있다.
노출해도 되는 상황이 있나요?
하지만 pakage-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출하는 것이 나을 수도 있다. 그 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 된다. 이 방식은 클래스 선언 면에서나, 이를 사용하는 클라이언트 코드 면에서는 접근자 방식보다 훨씬 깔끔하다. 특히 private 중첩 클래스의 경우는 수정 범위가 더 좁아진다.
최대한 직접 노출하지 말자
자바의 필드 노출
자바에서도 "public 클래스의 필드를 직접 노출하지 말라"는 규칙을 어기는 사례가 종종 있다. 대표적으로 java.awt.package 패키지의 Point와 Dimension 클래스다. 이게 옳다는 것이 절대 아니다. (Item67)에서 말하듯, 내부를 노들한 Dimension 클래스의 심각한 성능 문제는 오늘날까지 해결되지 못했다.
불변 필드는 노출해도 괜찮지 않나요?
public 클래스의 필드가 불변이라면 직접 노출시 괜찮을 것 같지만, 여전히 좋은 생각이 아니다. 필드를 읽을 때 부수 작접을 수행할 수 없다는 단점은 여전하다. (그래도 불변식은 보장한다.)
'JAVA > Effective Java' 카테고리의 다른 글
[이펙티브 자바] 상속보다는 컴포지션을 사용하라 ─ 4장:클래스와 인터페이스:Item18 (1) | 2023.10.30 |
---|---|
[이펙티브 자바] 변경 가능성을 최소화하라 ─ 4장:클래스와 인터페이스:Item17 (0) | 2023.10.25 |
[이펙티브 자바] 클래스와 멤버의 접근 권한을 최소화하라 ─ 4장:클래스와 인터페이스:Item15 (1) | 2023.10.24 |
[이펙티브 자바] 최적화는 신중히 사용하라 ─ 9장:일반적인 프로그래밍 원칙:Item67 (0) | 2023.10.22 |
[이펙티브 자바] 네이티브 메서드는 신중히 사용하라 ─ 9장:일반적인 프로그래밍 원칙:Item66 (0) | 2023.10.22 |