반응형
public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
class Point {
public double x;
public double y;
}다음과 같은 클래스 설계는 퇴보한 클래스이다. 이런 클래스는 데이터 필드에 직접 접근할 수 있기 때문에 캡슐화의 이점을 제공하지 못한다.
API를 수정하지 않고는 내부 표현을 바꿀 수 없고, 외부 접근이 가능하기 때문에 불변식을 보장할 수 없으며, 외부에서 필드에 접근할 때 부수 작업을 수행할 수도 없다.
class Point {
private double x;
private double y;
public Point(double x, double y) {
this.x = x;
this.y = y;
}
// Getter & Setter
}Getter와 Setter를 활용해 기존의 필드의 정보 private을 통해 숨기고 필드의 내용을 사용하기 위한 Getter & Setter 메서드를 사용했다.
그 결과 패키지 바깥에서 접근할 수 있고, 공개된 내부 표현 방식을 사용해서 외부 부수 작업을 진행할 수 있게 된다.
package-private 클래스 혹은 private 중첩 클래스라면 데이터 필드를 노출한다 해도 아무 문제가 없다.
대신 그 클래스가 표현하려는 추상 개념만 올바르게 표현해주면 된다.
자바 플랫폼 라이브러이에서도 public 클래스의 필드를 직접 노출하지 말라는 규칙을 어긴 사례가 있다.
java.awt.package의 Point와 Dimension 클래스가 이에 해당 된다. 잘못된 설계로 인해 Dimension 클래스의 성능 문제는 현재도 해결되지 못하고 있다.
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)
throw new IllegalArgumentException("시간 : " + hour);
if (minute < 0 || minute >= MINUTES_PER_HOUR)
throw new IllegalArgumentException("분 : " + minute);
this.hour = hour;
this.minute = minute;
}
}- public 클래스에서 불변 필드를 직접 노출하는 것은 가변 필드의 단점보다는 줄어들지만, 좋은 설계는 아니다. 불변식은 보장할 수 있지만, API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점은 여전하다.
public 클래스는 절대 가변 필드를 직접 노출해서는 안된다.
불변 필드라면 노출해도 덜 위험하지만 완전히 안심할 수는 없다.
하지만 package-private 클래스나 private 중첩 클래스에서는 불변 여부와 관계 없이 필드를 노출하는 편이 나을 때도 있다.
반응형
