Item 17. 변경 가능성을 최소화하라
불변 클래스는 인스턴스 내부 값을 수정할 수 없는 클래스입니다. 인스턴스에 저장된 정보는 고정되어 객체가 소멸하는 순간까지 절대 달라지지 않습니다. 자바 플랫폼 라이브러리의 String, 기본 타입 박싱 클래스들, BigInteger, BigDecimal이 불변 클래스의 대표적인 예시입니다.
불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전합니다.
불변 클래스의 다섯 가지 규칙
객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.
클래스를 확장할 수 없도록 한다.
하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 상태를 막아줍니다. 대표적인 방법으로는 클래스를 final로 선언하는 방법이 있습니다.
모든 필드를 final로 선언한다.
시스템이 강제하는 수단을 이용해 설계자의 의도를 드러내는 방법입니다. 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하는 데도 필요한 방법입니다.(자바 언어 명세의 메모리 모델 부분 참고)
모든 필드를 private으로 선언한다.
필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아줍니다. 기술적으로는 기본 타입 필드나 불변 객체를 참조하는 필드를 public final로만 선언해도 불변 객체가 되지만, 이렇게 하면 다음 릴리스에서 내부 표현을 바꾸지 못하므로 권하지는 않습니다.
자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.
클래스에 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야 합니다. 이런 필드는 절대 클라이언트가 제공한 객체 참조를 가리키게 해서는 안 되며, 접근자 메서드가 그 필드를 그대로 반환해서도 안 됩니다. 생성자, 접근자, readObject 메서드(Item 88) 모두에서 방어적 복사를 수행해야합니다.
불변 클래스 예시
// 코드 17-1 불변 복소수 클래스
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);
}
// 코드 17-2 정적 팩터리(private 생성자와 함께 사용해야 한다.) (110-111쪽)
public static Complex valueOf(double re, double im) {
return new Complex(re, 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)";
}
}위 클래스의 사칙연산 메서드(plus, minus, times, dividedBy)들은 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어 반환합니다. 이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피 연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 합니다.
메서드 이름으로 (add 같은) 동사 대신 (plus 같은) 전치사를 사용하였는데, 이는 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도입니다. 이 명명 규칙을 따르지 않은 BigInteger와 BigDecimal 클래스를 사람들이 잘못 사용해 오류가 발생하는 일이 자주 생깁니다.
함수형 프로그래밍 방식으로 프로그래밍하면 코드는 불변이 되는 영역의 비율이 높아지는 장점이 있습니다. 불변 객체는 단순합니다. 불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직합니다. 모든 생성자가 클래스 불변식(class invariant)을 보장한다면 그 클래스를 사용하는 프로그래머가 다른 노력을 들이지 않더라도 영원히 불변으로 남습니다.
불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요가 없습니다. 여러 스레드가 동시에 사용해도 절대 훼손되지 않으며, 그 어떤 스레드도 다른 스레드에 영향을 줄 수 없으므로 불변 객체는 안심하고 공유할 수 있습니다. 따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하는 것이 좋습니다. 가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것입니다.
public static final Complex ZERO = new Complex(0, 0);
public static final Complex ONE = new Complex(1, 0);
public static final Complex I = new Complex(0, 1);이 방식에 더해서, 불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리(Item 1)를 제공할 수 있습니다. 박싱된 기본 타입 클래스 전부와 BigInteger가 여기에 속합니다. 이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어듭니다.
불변 객체는 방어적 복사(Item 50)도 필요 없습니다. 아무리 복사해봐야 원본과 똑같으므로 복사 자체가 의미가 없습니다. 따라서 불변 클래스는 clone 메서드나 복사 생성자(Item 13)를 제공하지 않는 게 좋습니다.
불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있습니다. 예시로 BigInteger 클래스는 내부에서 부호(sign) 변수와 와 크기(magnitude) 배열을 따로 표현하는데, negate 메서드와 같이 크기가 같고 부호만 반대인 새로운 BigInteger를 생성하는 경우, 배열이 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 됩니다.
객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많습니다. 값이 바뀌지 않는 구성요소들로 이뤄진 객체라면 그 구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월하기 때문입니다. 좋은 예로, 불변 객체는 맵의 키와 집합(Set)의 원소로 쓰기 안성맞춤입니다. 맵이나 집합은 안에 담긴 값이 바뀌면 불변식이 허물어지는데, 불변 객체를 사용하면 그런 걱정을 덜 수 있습니다.
불변 객체는 그 자체로 실패 원자성을 제공합니다.(Item 76). 상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없습니다.
실패 원자성(failure atomicity): 메서드에서 예외가 발생한 후에도 그 객체는 여전히 (메서드 호출 전과 똑같은) 유효한 상태여야 한다는 성질. 불변 객체의 메서드는 내부 상태를 바꾸지 않으니 이 성질을 만족합니다.
불변 클래스에도 단점은 있습니다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 것입니다. 예컨데 백만 비트짜리 BigInteger에서 비트 하나만 바꾸더라도 새로히 객체를 생성해야 합니다.
BigInteger moby = ...;
moby = moby.flipBit(0);원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려지게된다면 성능 문제는 더 불거집니다. 이 문제는 두 가지 방법으로 대처할 수 있습니다.
-
흔히 쓰일 다단계 연산(multistep operation)들을 예측하여 기본 기능으로 제공하는 방법.
이러한 다단계 연산을 불변 객체 내부적으로 아주 영리한 방식으로 구현하여 기본으로 제공한다면 더 이상 각 단계마다 객체를 생성하지 않아도 됩니다. 예시로 BigInteger에서는 모듈러 지수 같은 다단계 연산 속도를 높여주는 가변 동반 클래스(companion class)를 package-private로 가지고 있고 이를 기본 기능으로 제공합니다.
-
다단계 연산(multistep operation)들을 정확히 예측할 수 없을 경우, 가변 동반 클래스(companion class)를 클라이언트에게 제공하는 방법.
클라이언트들이 원하는 복잡한 연산을 정확히 예측할 수 없다면 가변 동반 클래스를 package-private이 아닌 public으로 제공하는 것도 방법입니다. 자바 플랫폼 라이브러리에서 제공하는 StringBuilder와 StringBuffer가 대표적인 예시입니다.
불변 클래스를 만드는 또 다른 설계 방법
클래스가 불변임을 보장하려면 자신을 상속하지 못하게 해야합니다. 자신을 상속하지 못하게 하는 가장 쉬원 방법은 final 클래스로 선언하는 것이지만, 더 유연한 방법이 있습니다. 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 방법입니다(Item 1).
public class Complex {
private final double re;
private final double im;
private Complex(double re, double im) {
this.re = re;
this.im = im;
}
public static Complex valueOf(double re, double im) {
return new Complex(re, im);
}
...
}바깥에서 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 훨씬 유연합니다. public이나 protected 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는 게 불가능하기 때문에, 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final입니다. 정적 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이에 더해 다음 릴리스에서 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있습니다.
BigInteger와 BigDecimal을 설계할 당시엔 불변 객체가 사실상 final이어야 한다는 생각이 퍼지기 전이었으므로, 이 두 클래스의 메서드들은 모두 재정의할 수 있게 설계되었습니다. 만약 신뢰할 수 없는 클라이언트로부터 BigInteger와 BigDecimal의 인스턴스를 인수로 받는다면 진짜 BigInteger 혹은 BigDecimal인지 확인해야 합니다.
모든 필드가 final이고 어떤 메서드도 그 객체를 수정할 수 없어야 한다는 규칙은 조금 과한 감이 있어서, 성능을 위해 다음처럼 살짝 완화할 수 있습니다. "어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다." 어떤 불변 클래스는 계산 비용이 큰 값을 나중에 (처음 쓰일 때) 계산하여 final이 아닌 필드에 캐시해놓기도 합니다. 똑같은 값을 다시 요청하면 캐시해둔 값을 반환하여 계산 비용을 절감할 수 있습니다.
예시로 PhoneNumber의 hashCode 메서드(Item 11)는 처음 불렸을 때 해시 값을 계산해 캐시합니다.
직렬화할 때는 추가로 주의할 점이 있습니다. Serializable을 구현하는 불변 클래스의 내부에 가변 객체를 참조하는 필드가 있다면 readObject나 readResolve 메서드를 반드시 제공하거나, ObjectOutputStrea.writeUnshared와 ObjectInputStream.readUnshared 메서드를 사용해야 합니다. 그렇지 않으면 공격자가 이 클래스로부터 가변 인스턴스를 만들어 낼 수 있기 때문입니다. (Item 88)
정리
- 게터(getter)가 있다고 해서 무조건 세터(setter)를 만들지는 말자.
- 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
- 불변 클래스는 장점이 많으며, 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐이다.
- 단순한 값 객체는 항상 불변으로 만들자(자바 플랫폼에서도 원래는 불변이어야 했지만 그렇지 않게 만들어진 객체가 몇 개 있다(java.util.Date, java.awt.Point)).
- String과 BigInteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 고심해야 한다. 성능 때문에 어쩔 수 없다면(item 67) 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자.
- 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자. 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다. 그러니 꼭 변경해야 할 필드를 뺀 나머지 모두를 final로 선언하자. 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
- 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다. 확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안 된다. 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안 된다. 복잡성만 커지고 성능 이점은 거의 없다.
출처
