변경 가능성을 최소화하라

불변 클래스

인스턴스의 내부 값을 수정할 수 없는 클래스. 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.

불변 클래스 생성 규칙

객체의 상태를 변경하는 메서드를 제공하지 않는다.
클래스를 확장할 수 없도록 한다.
모든 필드를 final로 선언한다.
모든 필드를 private으로 선언한다.
자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

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

    // 정적 팩터리(private 생성자와 함께 사용해야 한다.)
    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;

        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)를 사용한 점에도 주목하자. 이는 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도다.

불변 객체 공유

불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없다. 여러 스레드가 동시에 사용해도 절대 훼손되지 않는다. 따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권한다. 가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수로 제공하는 것이다.

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

불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있다. 박싱된 기본 타입 클래스와 BigInteger가 여기 속한다. 이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.
새로운 클래스를 설계할 때 public 생성자 대신 정적 팩터리를 만들어두면, 클라이언트를 수정하지 않고도 필요에 따라 캐시 기능을 덧붙일 수 있다.
불변 객체는 방어적 복사가 필요없다. 그래서 clone 메서드나 복사생성자를 제공하지 않는 게 좋다.

불변 객체끼리의 내부 데이터 공유

불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다. 예컨대 BigInteger 클래스는 내부에서 값은 부호와 크기를 따로 표현한다. 부호에는 int 변수를, 크기에는 int 배열을 사용하는 것이다.
negate 메서드는 크기가 같고 부호만 반대인 새로운 BigInteger를 생성하는데, 이때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 된다. 그 결과 새로 만든 BigInteger 인스턴스도 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.

불변 객체의 장점

구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월하다. 좋은 예로 Map의 키와 Set의 원소로 쓰기에 안성맞춤이다.
불변 객체는 그 자체로 실패 원자성을 제공한다. 상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없다.

실패 원자성 : 메서드에서 예외가 발생한 후에도 그 객체는 여전히 유효한 상태여야 한다는 성질. 불변객체의 메서드는 내부 상태를 바꾸지 않으니 이 성질을 만족한다.

불변 객체의 단점

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

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

flipBit 메서드는 새로운 BigInteger 인스턴스를 생성하는데, 이 연산은 BigInteger의 크기에 비례해 시간과 공간을 잡아먹는다.
BigSet도 BigInteger처럼 임의의 길이의 비트 순열을 표현하지만, BigInteger와는 달리 가변이다.

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

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

불변 객체 생성 시 성능문제 대처

흔히 쓰일 다단계 연산들을 예측하여 기본 기능으로 제공하면 각 단계마다 객체를 생성하지 않아도 된다. BigInteger는 다단계 연산 속도를 높여주는 가변 동반 클래스를 package-private으로 두고 있다.
클라이언트들이 원하는 연산들을 예측할 수만 있다면 package-private의 가변 동반 클래스만으로 충분하다. 그렇지 않다면 이 클래스를 public으로 제공하는 게 최선이다. 자바 플랫폼 라이브러리에서 String 클래스가 대표적인 예다. StringBuilder가 가변 동반 클래스다.

불변 클래스는 계산 비용이 큰 값을 나중에 계산하여 final이 아닌 필드에 캐시해둘 수도 있다. 똑같은 값을 다시 요청하면 캐시해둔 값을 반환하여 계산 비용을 절감하는 것이다. 그렇게 되면 “모든 필드가 final이고 어떤 메서드도 그 객체를 수정할 수 없어야 한다.” 라는 규칙을 “어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다.”로 완화해야 한다.

불변클래스 작성 요령

생성자 대신 정적 팩터리를 사용하자.

final 클래스로 선언하여 자신을 상속하지 못하게 하는 방법보다 더 유연하게, 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 방법이 있다.

public final 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 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 훨씬 유연하다. 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다. 정적 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이에 더해 다음 릴리스에서 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.

Serializable을 구현하는 불변 클래스의 내부에 가변 객체를 참조하는 필드가 있다면 readObject나 readResolve 메서드를 반드시 제공하거나, ObjectOutputStream.writeUnshared와 ObjectInputStream.readUnshared 메서드를 사용해야 한다. 플랫폼이 제공하는 기본 직렬화 방법이면 충분하더라도 말이다. 그렇지 않으면 공격자가 이 클래스로부터 가변 인스턴스를 만들어낼 수 있다.

getter가 있다고 해서 무조건 setter를 만들지는 말자.

클래스가 꼭 필요한 경우 아니라면 불변이어야 한다. 불변 클래스는 장점이 많으며, 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐인다. 성능 때문에 어쩔 수 없다면 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자.

불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소화하자.

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

생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.

확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안 된다.

Twitter Facebook LinkedIn