불변 클래스란?

• 인스턴스의 내부 값을 수정할 수 없는 클래스
• String, 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal이 여기 속한다.

클래스를 불변으로 만드는 다섯 가지 규칙

1) 객체의 상태를 변경하는 메서드(변경자, Setter)를 제공하지 않는다.

2) 클래스를 확장할 수 없도혹 해야 한다.

• 클래스를 final로 선언
• private 생성자를 두고 public 정적 팩터리를 제공

3) 모든 필드를 final로 선언

• 설꼐자의 의도를 명확히 드러내는 방법이다.

4) 모든 필드를 private 으로 선언한다.

• 기술적으론 기본 타입 필드나 불변 객체를 참조하는 필드를 public final 로만 선언해도 불변 객체가 되지만, 이렇게 하면 클라이언트는 직접적으로 해당 필드에 접근할 수 있기에 추후 내부 표현(필드 변수명)을 바꾸지 못하므로 권하지 않는다.

5) 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

• 생성자, 접근자, readObject 메서드(아이템88) 모두에서 방어적 복사를 수행해야 한다.

불변 클래스를 사용한 예시 Complex 클래스

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

// 코드 17-1 불변 복소수 클래스 (106-107쪽)
public final class Complex {
    private final double re;
    private final double im;

    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);

    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)";
    }
}

• 이 클래스는 복소수(실수부와 허수부로 구성된 수)를 표현한다.
• Object의 메서드 몇 개를 재정의했고, 실수부와 허수부값을 반환하는 접근자 메서드(readPar와 imaginaryPart)와 사칙역산 메서드(plus, minus times, dividedBy)를 정의했다.
• 이 사칙연산 메서드들이 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어 반환하는 모습에 주목하자.
  • 이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다.
  • 이와 달리, 절차적 혹은 명령형 프로그래밍에선 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.
• 또한 메서드 이름으로 (add 같은) 동사 대신 (plus 같은) 전치사를 사용한 점에도 주목하자. 이는 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도다.
  • 개인적으로 이 부분은 공감이 아직 조금 힘든 것 같다. 전치사로 메서드명을 바꿨을때 객체의 값을 변경하지 않는다는 사실을 강조한다는 부분이 직관적으로 아직은 와닿지는 않는다.
• 함수형 프로그래밍은 불변이 되는 영역의 비율이 높아지는 장점을 누릴 수 있다.
• 불변 객체는 단순하다. 불변 객체는 생성된 시점의 상태를 파괴될때 까지 그대로 간직한다.
• 반면, 가변 객체는 임의의 복잡한 상태에 놓일 수 있으며 믿고 사용하기 어려울 수도 있다.

불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다.

• 왜? 객체 내부의 상태값이 변하지 않는다는 것을 보장해주기 때문이다.
• 동시성 문제도 read만 있을 경우엔 문제가 되지 않는다. write 가 있을 경우엔 문제가 될 소지가 있다.
• 사실 불변 클래스를 만드는게 스레드 안전하게 만드는 가장 쉬운 방법이기도 하다.
• 불변 객체는 위와 같은 이유로 안심하고 공유할 수 있으므로, 불변 클래스라면 한 번 만든 인스턴스를 최대한 재활용하기를 권한다.
  • 가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것이다. 예컨대 Complex 클래스는 아래와 같은 상수들을 제공할 수 있다.

1
2
3

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);

불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리(아이템1)를 제공할 수 있다.

• 박싱된 기본 타입 클래스 전부와 BigInteger가 여기 속한다.
• 이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.
• 새로운 클래스를 설계할 때 public 생성자 대신 정적 팩터리를 만들어두면, 클라이언트를 수정하지 않고도 필요에 따라 캐시 기능을 나중에 덧 붙일 수 있다.

분변 객체를 자유롭게 공유할 수 있다는 점은 방어적 복사(아이템50)도 필요 없다는 결론으로 자연스럽게 이어진다.

• 아무리 복사해봐야 원본과 똑같으니 복사 자체가 의미가 없다.
• 그러니 불변 클래스는 clone 메서드나 복사 생성자(아이템13)를 제공하지 않는게 좋다. 굳이 메모리가 낭비만 될 뿐이라고 생각한다.
• String 클래스의 복사 생성자는 이 사실을 잘 이해하지 못한 자바 초창기 때 만들어진 것으로, 되도록 사용하지 말아야 한다.(아이템6)

불변 객체끼리는 내부 데이터를 공유할 수 잇따.

• 예컨대 BigInteger 클래스는 내부에서 값의 부호(sign)와 크기(magnitude)를 따로 표현한다.
• 부호는 int 변수를, 크기(절대값)에는 int 배열을 사용한다.
• 한편 negate 메서드 는 크기가 같고 부호만 반대인 새로운 BigInteger를 생성하는데 이때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 된다. 그 결과 새로 만든 BigInteger클래스는 원본 인스턴스가 가리키는 내부 배열을 가리킨다.

객체를 만들때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다.

• 값이 바뀌지 않는 구성요소들로 이뤄진 객체라면 그 구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월하기 때문이다.
• 좋은 예로, 불변 객체는 맵의 키와 집합(Set)의 원소로 쓰기에 안성맞춤이다.
  • 맵이나 집합은 안에 담긴 값이 바뀌면 불변식이 허물어지는데, 불변 객체를 사용하면 그런 걱정은 하지 않아도 된다.

불변 객체는 그자체로 실패 원자성을 제공한다.(아이템76)

• 상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없다.
• 실패 원자성(failure atomicity)이란 ‘메서드에서 예외가 발생한 후에도 그 객체는 여전히 호출 전과 똑같은 유효한 상태여야 한다’는 성질이다. 불변 객체의 메서드는 내부 상태를 바꾸지 않으니 이 성질을 만족한다.

불변 클래스에도 단점은 있다. 값이 다르면 반드시 독립된 객체로 만들어야 한다는 것이다.

• 값의 가짓수가 많다면 이들을 모두 만드는데 큰 비용을 치러야 한다. 예컨대 백만 비트짜리 BigInteger 에서 비트 하나를 바꿔야 한다고 해보자.

1
2

BigInteger moby = ...;
moby = moby.flipBit(0);

• flipBit 메서드는 새로운 BigInteger 인스턴스를 생성한다. 원본과 단지 한 비트만 다른 백만 비트짜리 인스턴스를 말이다.
• 이 연산은 BigInteger 의 크기에 비례해 시간과 공간을 잡아먹는다.
• BitSet도 BigInteger 처럼 임의 길이의 비트 순열을 표현하지만, BigInteger 와는 달리 가변이다.
• BitSet 클래스는 원하는 비트 하나만 상수 시간안에 바꿔주는 메서드를 제공한다.

1
2

BitSet moby = ...;
moby.flip(0);

• 원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제가 더 불거진다.
• 이 문제에 대처하는 방법은 두 가지다.

1) 흔히 쓰일 다단계 연산들을 예측하여 기본 기능으로 제공하는 방법이다.

• 이러한 다단계 연산을 기본으로 제공한다면 더 이상 각 단계마다 객체를 생성하지 않아도 된다.

2) 클라이언트들이 원하는 복잡한 연산들을 정확히 예측할 수 있다면 package-private 의 가변 동반 클래스만으로 충분하다.

• 그렇지 않다면 이 클래스를 public 으로 제공하는게 최선이다.
• 자바 플랫폼 라이브러리에서 이에 해당하는 대표적인 예가 String 클래스이다.
• 그렇다면 String의 가변 동반 클래스는? 바로 StringBuilder와 구닥다리 전임자 StringBuffer이다.

상속할 수 없는 클래스를 만드는 더 유연한 방법은 public 정적 팩터리를 제공하는 것이다.

• 가장 쉬운 방법은 final 클래스로 선언하는 것이다.
• 이보다 더 유연한건 public 정적 팩터리를 제공하는 것이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class Complex {
    private final double re;
    private final double im;

    private Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }

    // 코드 17-2 정적 팩터리(private 생성자와 함께 사용해야 한다.) (110-111쪽)
    public static Complex valueOf(double re, double im) {
        return new Complex(re, im);
    }
    
    ... // 나머지 코드 생략
}

Note: 정잭 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 추후 클라이언트 코드의 변경 없이 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.

BigInteger와 BigDecimal을 설꼐할 당시엔 불변 객체가 사실상 final이어야 한다는 생각이 널리 퍼지지 않았다.

• 그래서 이 두 클래스의 메서드들은 모두 재정의할 수 있게 설계되었고, 안타깝게도하위 호완성이 발목을 잡아 지금까지도 이 문제를 고치지 못했다.
• 그러므로 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면, 이 인수들을 가변이라 가정하고 방어적으로 복사해 사용해야 한다.(아이템50)

1
2
3

public static BigInteger safeInstance(BigInteger val) {
    return val.getClass() == BigInteger.class ? val : new BigInteger(val.toByteArray());
}

불변 클래스의 모든 필드가 final이고 어떤 메서드도 그 객체를 수정할 수 없어야 한단 불변 클래스 규칙은 좀 과한 감이 있기에, 성능을 위해 다음처럼 살짝 완화할 수 있다.

• “어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다.”
• 어떤 불변 클래스는 계산 비용이 큰 값을 나중에(처음 쓰일 때) 계산하여 final이 아닌 필드에 캐시 해놓기도 한다.
  • 똑같은 값을 다시 요청하면 캐시해둔 값을 반환하여 계산 비용을 절감하는 것이다.
  • 이 묘수는 객체가 불변이기 때문에 가능하고 몇 번을 계산해도 항상 같은 결과가 만들어짐이 보장되기 때문이다.
• 예컨대 PhoneNumber의 hashCode 메서드(아이템11, 71페이지)는 처음 불렸을 때 해시 값을 계산해 캐시한다. 지연 초기화(아이템 83)의 예이기도 한 이 기법을 String도 사용한다.

1
2
3
4
5
6
7
8
9
10
11
12
13

// 해시코드를 지연 초기화하는 hashCode 메서드 - 스레드 안정성까지 고려해야 한다. (71쪽)
private int hashCode; // 자동으로 0으로 초기화된다.

@Override public int hashCode() {
    int result = hashCode;
    if (result == 0) {
        result = Short.hashCode(areaCode);
        result = 31 * result + Short.hashCode(prefix);
        result = 31 * result + Short.hashCode(lineNum);
        hashCode = result;
    }
    return result;
}

Note: 직렬화할 때는 추가로 주의할 점이 있다. Serializable을 구현하는 불변 클래스의 내부에 가변 객체를 참조하는 필드가 있다면 readObject나 readResolve 메서드를 반드시 제공하거나, ObjectOutputStream.writeUnshared와 ObjectInputStream.readUnshared 메서드를 사용해야 한다.

정리

1) 게터(getter)가 있다해서 무조건 세터(setter)를 만들진 말자.

2) 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.

3) 불변 클래스는 장점이 많으며 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐이다.

4) PhoneNumber와 Complex 같은 단순한 값 객체는 항상 불변으로 만들자.

5) String과 BigInteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 고심해야 한다.

• 성능 때문에 어쩔 수 없다면(아이템67) 불변 클래스와 쌍을 이루는 가변 동반 클래스(ex. StringBuilder)를 public 클래스로 제공하도록 하자.

6) 한편, 모든 클래스를 불변으로 만들 순 없다. 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.

• 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다.
• 그러니 꼭 변경해야 할 필드를 뺀 나머지 모두를 final로 선언하자.

7) 이번 아이템과 아이템 15의 조언을 종합하면 다음과 같다. “다른 합당한 이유가 없다면 모든 필드는 private final 이어야 한다.”

8) 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다. 확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해선 안된다.

• 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안된다. 복잡성만 커지고 성능 이점은 거의 없다.

9) java.util.concurrent 패키지의 CountDownLatch 클래스가 이상의 원칙을 잘 방증한다.

• 비록 가변 클래스지만 가질 수 있는 상태의 수가 많지 않다. 인스턴스를 생성해 한 번 사용하고 그걸로 끝이다. 카운트가 0에 도달하면 더는 재사용할 수 없는 것이다.

Note: 이번 아이템에서 다룬 Complex 클래스는 설명을 위한 예시일 뿐 실무에서 쓸만한 수준은 못되니 참고바란다.