[item 17] 변경 가능성을 최소화하라

 불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다.불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.

 

[ 불변 클래스의 다섯 가지 규칙 ]

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

2. 클래스를 확장할 수 없도록 한다. 상속을 막는 대표적인 방법은 클래스를 final로 선언하는 것이다.

3. 모든 필드를 final로 선언한다. 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하는데도 필요하다.

4. 모든 필드를 private으로 선언한다. 필드가 참조하는 가변 객체를 클라이언트가 직접 접근해 수정하는 일을 막아준다.

5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 클래스에서 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수없도록 해야 한다.

 

[ 복소수 클래스에 대한 예제 ]

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

    @Override
    public boolean equals(Object o) {
        if(o == this) return true;
        if(!(o instanceof Complex)) return false;

        Complex c = (Complex) o;

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

 이 클래스는 복소수를 표현한다. 사칙연산 메서드들이 인스턴스 자신은 수정하지 않고, 새로운 Complex 인스턴스를 만들어 반환하는 모습에 주목하자. 이처럼 피연산자에 대한 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다. 이 방식으로 프로그래밍하면 코드에서 불변이 되는 영역의 비율이 높아지는 장점을 누릴 수 있다.

 

[ 불변 객체의 특징 ]

1. 불변 객체는 단순하다. 생성된 시점의 상태를 파괴할 때까지 그대로 간직한다.

2. 불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다. 불변 객체에 대해서는 그 어떤 스레드도 다른 스레드에 영향을 줄 수 없으니 안심하고 공유할 수 있다. 따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권한다.

 예를 들어 Complex 클래스는 다음 상수들을 제공할 수 있다.

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

 

3. 불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있다. 이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.

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

5. 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.

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

7. 불변 객체는 그 자체로 실패 원자성을 제공한다.

8. 불변 클래스는 값이 다르면 반드시 독립된 객체로 만들어야 한다. 값의 가짓수가 많다면 이들을 모두 만드는 데 큰 비용을 치러야한다.

 

[ BigInteger로 보는 불변 객체의 단점과 해결법 ]

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

flipBit 메서드는 새로운 인스턴스를 생성한다. 원본과 단지 한 비트만 다른 인스턴스를 생성한다는 의미가 된다. 이 연산은 BigInteger의 크기에 비례해 시간과 공간을 잡아먹는다.

 

 이러한 문제에 대처하는 방법은 흔히 쓰일 다단계 연산들을 예측하여 기본 기능으로 제공하는 것이다. 예컨대 BigInteger는 모듈러 지수같은 다단계 연산 속도를 높여주는 가변 동반 클래스를 package-private으로 두고 있다. 자바 플랫폼 라이브러리에서는 클래스를 public으로 제공하는 String이 있다. 그리고 String의 가변 동반 클래스가 바로 StringBuilder다.

 

[ 불변 클래스를 만드는 또 다른 설계 방법 ]

 클래스가 불변임을 보장하려면 자신을 상속하지 못하게 해야 한다. 가장 쉬운 방법은 클래스를 final로 선언하는 것지만, 더 유연한 방법은 모든 생성자를 private 혹은 package-private으로 만들고, public 정적 팩터리를 제공하는 방법이다.

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

 정적 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이에 더해 다음 릴리즈에서 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.

 

※ 직렬화할 때는 주의할 점이 있다. Serializable을 구현하는 불변 클래스의 내부에 가변 객체를 참조하는 필드가 있다면 readObject나 readResolve 메서드를 반드시 제공하거나, ObjectOutputStream.writeUnshared와 ObjectInputStream.readUnshared 메서드를 사용해야 한다. 이렇지 않으면 이 클래스로부터 가변 인스턴스를 만들어낼 수 있다.

 

[ 요약 ]

 정리해본다면, getter가 있다고 해서 무조건 setter를 만들지는 말자. 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다. String과 BigInteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 고심해야한다. 성능 때문에 어쩔 수 없다면 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자.

 

 한편, 모든 클래스를 불변으로 만들 수는 없다. 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자. 꼭 변경해야할 필드를 뺀 나머지 모두를 final로 선언하자.

 확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안된다. 객체를 재활용할 목적으로 상태를 다시 초기화하는 매서드도 안된다.