티스토리 뷰
프로그래밍/EffectiveJava
(이펙티브 자바) 규칙16. public 클래스에서는 public필드가 아닌 접근자 메서드를 사용하라
rlawlstjd007 2020. 2. 26. 17:47(Effective Java) 규칙16. public 클래스에서는 public필드가 아닌 접근자 메서드를 사용하라
public 필드의 문제
-
인스턴스 필드들을 모아놓는 일 외에는 아무 목적도 없는 퇴보한 클래스를 작성하려 할 때가 있다.
class Point { public double x; public double y; }
- 이런 클래스는 데이터필드에 직접 접근할 수 있으니 캡슐화의 이점을 제공하지 못함
- API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 불변식을 보장할 수 없음
- 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없음
접근자 메서드
-
public 클래스에서라면 아래의 방식이 확실히 맞다.
class Point { private double x; private double y; public Point(double x, double y) { this.x = x; this.y = y; } public double getX() { return x; } public void setX(double x) { this.x = x; } public double getY() { return y; } public void setY(double y) { this.y = y; } }
- 패키지 바깥에서 접근할 수 있는 클래스라면 접근자를 제공함으로써 클래스 내부 표현 방식을 언제든 바쑬 수 있는 유연성을 얻을 수 있음
- public 클래스가 필드를 공개하면 이를 사용하는 클라이언트가 생겨날 것이므로 내부 표현 방식을 마음대로 바꿀 수 없게 됨
-
하지만 package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출한다 해도 하등의 문제가 없다.
- 그 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 됨
-
자바 플랫폼 라이브러리에도 public 클래스의 필드를 직접 노출하지 말라는 규칙을 어기는 사례가 종종 있다.
- 대표적인 예가
java.awt.package
패키지의Point
와Dimension
클래스 - 특히,
Dimension
클래스의 심각한 성능 문제는 오늘날까지도 해결되지 못함
- 대표적인 예가
-
public 클래스의 필드가 불변이라면 직접 노출할 때의 단점이 조금은 줄어들지만, 좋은 생각은 아니다.
- API를 변경하지 않고는 표현방식을 바꿀수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전
public final class Time { private static final int HOURS_PER_DAY = 24; private static final int MINUTES_PER_HOUR = 60; public final int hour; public final int minute; public Time(int hour, int minute) { if (hour < 0 || hour >= HOURS_PER_DAY) return new IllegalArgumentException("시간: " + hour); if (minute < 0 || minute >= MINUTES_PER_HOUR) { throw new InterruptedException("분: " + minute); } this.hour = hour; this.minute = minute; } }
- API를 변경하지 않고는 표현방식을 바꿀수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전
결론
-
public클래스는 절대 가변 필드를 직접 노출해서는 안된다.
- 불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다.
-
하지만 package-private 클래스나 private 중첩 클래스에서는 종종(불변이든 가변이든) 필드를 노출하는 편이 나을 때도 있다.
끝으로
이 글이 도움이 되었다면, Google 광고 한번씩 클릭 부탁 드립니다. 🙏🙏🙏
광고 클릭은 많은 힘이 됩니다!
반응형
'프로그래밍 > EffectiveJava' 카테고리의 다른 글
(이펙티브 자바) 규칙58. 전통적인 for 문보다는 for-each 문을 사용하라 (0) | 2020.02.29 |
---|---|
(이펙티브 자바) 규칙57. 지역변수의 범위를 최소화하라 (0) | 2020.02.28 |
(이펙티브 자바) 규칙12. toString을 항상 재정의하라 (0) | 2020.02.25 |
(이펙티브 자바) 규칙7. 다 쓴 객체 참조를 해제하라 (0) | 2020.02.24 |
(이펙티브 자바) 규칙22. 인터페이스는 타입을 정의하는 용도로만 사용하라 (0) | 2020.02.20 |
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
TAG
- intelij
- 일본 배낭여행
- springboot
- 일본 자전거 여행
- 배낭여행
- 텐트
- 이펙티브
- windows
- 이펙티브 자바
- 배낭 여행
- JavaFX Table View
- git
- 자전거
- effective java
- 인텔리제이
- 방통대 과제물
- JavaFX
- 이펙티브자바
- JavaFX 종료
- java
- 일본 여행
- 스프링부트
- 자바
- JavaFX 테이블뷰
- JavaFX Window Close
- Java UI
- TableView
- 자전거 여행
- 일본여행
- effectivejava
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
글 보관함