불변 클래스란?
- 인스턴스의 내부 값을 수정할 수 없는 클래스
- 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다.
- 자바 플랫폼 라이브러리에서의 예시) String, 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal
[Why]
- 가변 클래스보다 설계하고 구현하고 사용하기 쉽다.
- 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용할 수 있다.
자주 사용되는 인스턴스를 캐싱하여 중복 생성되지 않게 해주는 정적 팩터리를 제공할 수 있다. 아이템1 - 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.
- 객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 그 구조가 아무리 복잡하더라도 불변식을 유지하기 수월하다.
- 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용할 수 있다.
- 오류가 생길 여지도 적고 훨씬 안전하다.
- 불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요가 없다. 따라서 안심하고 공유할 수 있다.
- 불변 객체를 자유롭게 공유할 수 있다는 점은 방어적 복사아이템50도 필요없다는 뜻이다.
clone 메서드나 복사 생성자를 제공하지 않는 게 좋다. String 클래스의 복사 생성자는 초창기의 유물이니 쓰지 말자. - 불변 객체는 그 자체로 실패 원자성을 제공한다. 아이템76
※ 실패 원자성(failure atomicity): '메서드에서 예외가 발생한 후에도 그 객체는 여전히 (메서드 호출 전과 똑같은) 유효한 상태여야 한다'는 성질
[How]
1. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.
- getter가 있다고 무조건 setter를 만들지는 말자.
2. 클래스를 확장할 수 없도록 한다.
- 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 사태를 막아준다.
- 상속을 막는 대표적인 방법은 클래스를 final로 선언하는 것이다. 다른 방법도 있다.
- 더 유연한 방법은, 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 것이다.
바깥에서 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있기 때문에 훨씬 유연하다.
패키지 바깥에서 본 이 불변 객체는 사실상 final이다. - 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안 된다. - BigInteger, BigDecimal은 재정의할 수 있게 설계되었다.
- 이 값들이 불변이어야 한다면 인수로 받은 객체가 진짜 BigInteger/BigDecimal인지 반드시 확인해야 한다.
- 만약 아니라면, 가변으로 가정하고 방어적으로 복사해서 사용해야 한다. 아이템50
3. 모든 필드는 final로 선언한다.
- 시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법이다.
- 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하는 데도 필요하다.
4. 모든 필드를 private으로 선언한다.
- 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
- 필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아준다.
- 기술적으로는 기본 타입 필드나 불변 객체를 참조하는 필드를 public final로만 선언해도 불변 객체가 되지만, 이렇게 하면 다음 릴리스에서 내부 표현을 바꾸지 못하므로 권하지는 않는다. 아이템15, 아이템16
5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.
- 클래스에 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야 한다.
- 이런 필드는 절대 클라이언트가, 제공한 객체 참조를 가리키게 해서는 안 되며 접근자 메서드가 그 필드를 그대로 반환해서도 안 된다.
- 생성자, 접근자, readObject 메서드아이템88 모두에서 방어적 복사를 수행하라.
(예시) 불변 복소수 클래스
public final class Complex {
private final double re;
private final double im;
public Complex(double re, double im) {
this.re = re;
this.im = im;
}
public double realPart() { return re; }
public double imaginaryPart() { return im; }
public Complex plus(Complex c) {
return new Complex(re + c.re, im + c.im);
}
public Complex minus(Complex c) {
return new Complex(re - c.re, im - c.im);
}
public Complex times(Complex c) {
return new Complex(re * c.re - im * c.im,
re * c.im + im * c.re);
}
public Complex dividedBy(Complex c) {
double tmp = c.re * c.re + c.im * c.im;
return new Complex(re * c.re + im * c.im / tmp,
im * c.re - re * c.im / tmp);
}
@Override
public boolean equals(Object o) {
if (o == this) {
return true;
}
if (!(o instanceof Complex)) {
return false;
}
Complex c = (Complex) o;
// == 대신 compare를 사용하는 이유는 63쪽을 확인하라.
return Double.compare(c.re, re) == 0
&& Double.compare(c.im, im) == 0;
}
@Override
public int hashCode() {
return 31 * Double.hashCode(re) + Double.hashCode(im);
}
@Override
public String toString() {
return "(" + re + " + " + im + "i)";
}
}
- 접근자 메서드(realPart, imaginaryPart)와 사칙연산 메서드(plus, minus, times, dividedBy)를 정의했다.
- 이 사칙연산 메서드들이 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어 반환하는 모습에 주목하자.
이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다.
절차적(명령형) 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다. - 메서드 이름으로 add 같은 동사 대신 plus 같은 전치사를 사용한 점도 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도다. 이 명명 규칙을 따르지 않은 BigInteger, BigDecimal 클래스를 잘못 사용해 오류가 발생하는 경우가 자주 있다.
불변 클래스의 단점
- 값이 다르면 반드시 독립된 객체로 만들어야 한다. 이들을 모두 만드는 데 큰 비용을 치러야 한다.
- 원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제가 더 불거진다.
e.g.) 백만 비트짜리 BigInteger에서 비트 하나를 바꿔주는 flipBit 메서드 → 단지 한 비트만 다른 백만 비트짜리 새 인스턴스를 생성 - 해결책 1
- 다단계 연산(multistep operation)들을 예측하여 기본 기능으로 제공하는 방법
- e.g.) BigInteger는 모듈러 지수 같은 다단계 연산 속도를 높여주는 가변 동반 클래스(companion class)를 package-private으로 두고 있음.
- 가변 동반 클래스의 사용은 매우 어렵지만 BigInteger가 알아서 다 처리해 줌.
- 해결책 2
- 클라이언트가 원하는 복잡한 연산을 정확히 예측해낼 수 없다면, 클래스를 public으로 제공하는 것이 최선
- e.g.) String 클래스
- String의 가변 동반 클래스는 StringBuilder, StringBuffer
'독서찰기(讀書札記) > 이펙티브 자바' 카테고리의 다른 글
[아이템 19] 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라. (0) | 2022.01.25 |
---|---|
[아이템 18] 상속보다는 컴포지션을 사용하라 (0) | 2022.01.25 |
[아이템 16] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 (0) | 2022.01.08 |
[아이템 15] 클래스와 멤버의 접근 권한을 최소화하라 (0) | 2022.01.08 |
[아이템 14] Comparable을 구현할지 고려하라 (0) | 2022.01.08 |