[Effective-Java] Item 17. 변경 가능성을 최소화하라

불변 클래스: 인스턴스 내부 값을 수정할 수 없는 클래스

불변 인스턴스에 간직된 정보는 고정되어 객체 파괴 순간까지 절대 달라지지 않는다.

불변 클래스는 가변 클래스보다 설계, 구현, 사용이 쉽고 오류가 생길 여지도 적으며 훨씬 안전하다.

ex) String, BigInteger, BigDecimal, Wrapper Class

 

 

불변클래스 규칙

---

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

ex) setter

2. 클래스를 확장할 수 없게 한다.

즉, 하위 클래스에서 부주의하게, 혹은 나쁜 의도로 객체의 상태를 변하게 하는 사태를 막아준다.

3. 모든 필드를 final로 선언한다.

시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법이다.

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

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

필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아준다. [아이템 15, 16 참조]

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

클래스에서 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야한다.

생성자, 접근자(getter), readObject 메소드(아이템 88) 모두에서 방어적 복사를 수행하자.

 

 

불변클래스 예시

---

 

// 복소수를 나타내는 클래스 (단순 예시용, 사용할 수준이 안됨)
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; }

    // 정적 팩터리(private 생성자와 함께 사용해야 한다.)
    public static Complex valueOf(double re, double im) {
        return new Complex(re, im);
    }
    
    // 아래 4개는 사친연산 메소드
    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;

        // Nan, 특수 부동 소수점 처리를 위해 compare 사용(p.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)";
    }
}

 

사칙연산 메소드들을 보면 인스턴스 자신을 수정하지 않고 새로운 인스턴스를 반환한다.

이러한 피연산자에 함수를 적용해 그 결과를 반환하지만 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라고 한다.

메소드 이름으로 add같은 동사 대신 plus같은 전치사를 사용한 점도, 해당 메소드가 객체의 값을 변경하지 않는다는 것을 강조하는 의도다.

 

위 예시코드처럼 함수형 프로그래밍으로 구현하면 코드에서 불변이 되는 영역의 비율이 높아지는 장점을 가진다.

불변 객체는 단순하다. 모든 생성자가 클래스 불변식을 보장하면 그 클래스를 사용하는 입장에서 다른 노력을 들이지 않아도 불변이다.

 

 

불변클래스 장점

---

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

여러 스레드가 동시에 사용해도 훼손되지 않는다.

 

2. 불변 객체는 안심하고 공유할 수 있다.

불변 객체에 대해서는 어떤 스레드도 다른 스레드에 영향을 줄 수 없기 때문이다.

 

따라서 불변 클래스면 한번 만든 인스턴스를 최대한 재사용 하길 권한다. ex) 상수(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);

 

혹은 자수 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩토리를 제공할 수 있다.

BigInteger와 Wrapper 클래스가 여기 속한다. 여러 클라이언트가 인스턴스를 공유하니 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.

 

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

아무리 복사해도 원본과 같으니 의미가 없다. 따라서 불변 클래스는 clone 메소드나 복사 생성자를 제공하지 않는게 좋다.

String 클래스의 복사 생성자는 이 사실을 잘 이해하지 못한 자바 초창기때 만들어져서 되도록 사용하지않는게 좋다.

 

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

예컨대 BigInteger 클래스를 보자

 

public class BigInteger extends Number implements Comparable<BigInteger> {
    final int signum; // 부호는 int 변수
    final int[] mag; // 크기(절대값)은 int 배열
    ...
    // 크기는 같고 부호만 반대인 새로운  BigInteger 생성
    // 배열은 가변이지만 복사하지않고 원본 인스턴스와 공유한다.
    public BigInteger negate() {
  	    return new BigInteger(this.mag, -this.signum);
    }
    ...
}

 

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

값이 바뀌지 않는 구성요소로 이뤄진 객체라면 그 구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월하다.

 

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

상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없다. [아이템 76 참조] 

*실패 원자성: 메소드에서 예외가 발생한 후에도 그 객체는 여전히 메소드 호출 전과 똑같은 유효한 상태여야 한다는 성질

 

불변클래스 단점과 해결방안

---

단점: 값이 다르면 반드시 독립된 객체로 만들어야 한다.

값의 가짓수가 많다면 이들을 모드 만드는 데 큰 비용을 치뤄야한다. 

 

    //BigInteger의 flipBit: 우측에서 n+1번째 비트를 전환(0이면 1, 1이면 0)하여 새 객체 반환
    public BigInteger flipBit(int n) {
        if (n < 0)
            throw new ArithmeticException("Negative bit address");

        int intNum = n >>> 5;
        int[] result = new int[Math.max(intLength(), intNum+2)];

        for (int i=0; i < result.length; i++)
            result[result.length-i-1] = getInt(i);

        result[result.length-intNum-1] ^= (1 << (n & 31));

        return valueOf(result);
    }
    //BigInteger의 valueOf: 새 객체를 반환
    private static BigInteger valueOf(int val[]) {
        return (val[0] > 0 ? new BigInteger(val, 1) : new BigInteger(val));
    }
    
    //BitSet의 flip: 자기 자신의 값을 수정
    public void flip(int bitIndex) {
        if (bitIndex < 0)
            throw new IndexOutOfBoundsException("bitIndex < 0: " + bitIndex);

        int wordIndex = wordIndex(bitIndex);
        expandTo(wordIndex);

        words[wordIndex] ^= (1L << bitIndex);

        recalculateWordsInUse();
        checkInvariants();
    }

 

 

BigInteger(불변)의 flipBit은 비트 하나를 바꾸는 연산을 해서 새 객체로 반환을 하기 때문에 O(n)의 시간 복잡도를 가지고

BitSet(가변)의 flip은 자신의 비트 하나를 바꾸는 연산을 하기 때문에 O(I)의 시간복잡도를 가진다. 

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

 

해결방안 두 가지

1. 다단계 연산(multistep operation)들을 예측하여 기본 기능으로 제공하는 방법

 

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

BigInteger는 모듈러 지수 같은 다단계 연산 속도를 높여주는 가변 동반 클래스(companion class)를 package-private으로 둔다.

그게 아래 코드에서는 MutalbeBigInteger다. 가변 동반 클래스는 사용하기 어려우나 BigInteger가 대신 다 처리해주는 것.

 

    // BigInteger의 modular Operation
    public BigInteger mod(BigInteger m) {
        if (m.signum <= 0)
            throw new ArithmeticException("BigInteger: modulus not positive");

        BigInteger result = this.remainder(m);
        return (result.signum >= 0 ? result : result.add(m));
    }
    
    public BigInteger remainder(BigInteger val) {
        if (val.mag.length < BURNIKEL_ZIEGLER_THRESHOLD ||
                mag.length - val.mag.length < BURNIKEL_ZIEGLER_OFFSET) {
            return remainderKnuth(val);
        } else {
            return remainderBurnikelZiegler(val);
        }
    }

    private BigInteger remainderBurnikelZiegler(BigInteger val) {
        return divideAndRemainderBurnikelZiegler(val)[1];
    }
    
    // 가변 동반 클래스며 package-private인 mutuableBigInteger을 호출
    private BigInteger remainderKnuth(BigInteger val) {
        MutableBigInteger q = new MutableBigInteger(),
                          a = new MutableBigInteger(this.mag),
                          b = new MutableBigInteger(val.mag);

        return a.divideKnuth(b, q).toBigInteger(this.signum);
    }
    
    // 가변 동반 클래스며 package-private인 mutuableBigInteger을 호출
    private BigInteger[] divideAndRemainderBurnikelZiegler(BigInteger val) {
        MutableBigInteger q = new MutableBigInteger();
        MutableBigInteger r = new MutableBigInteger(this).divideAndRemainderBurnikelZiegler(new MutableBigInteger(val), q);
        BigInteger qBigInt = q.isZero() ? ZERO : q.toBigInteger(signum*val.signum);
        BigInteger rBigInt = r.isZero() ? ZERO : r.toBigInteger(signum);
        return new BigInteger[] {qBigInt, rBigInt};
    }

 

밑에서 두 함수를 보면 다단계 연산을 위해 MutuableBigInteger라는 package-private 가변 동반 클래스를 호출함을 알 수 있다.

 

2. 복잡한 연산들을 정확히 다단계 연산으로 예측할 수 없을때 제공하는 방법

public으로 제공하는 게 최선이다. 자바 라이브러리에서는 String 클래스가 이에 해당한다.

String의 가변 동반 클래스는 StringBuilder/ StringBuffer다.

 

* 가변 동반 클래스: 기존 클래스와 거의 같은 기능을 하지만 가변 객체를 생성하는 클래스이다.

 

 

불변 클래스를 만드는 설계 방법

---

1. final 클래스로 선언

클래스가 불변임을 보장하려면 자신을 상속하지 못하게 해야하고, 가장 쉬운 방법은 final 클래스로 선언하는 것이다.

 

2. 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩토리를 제공

위의 불변 클래스 예시에 넣은 valueOf 메소드와 같다. 이 방식이 최선일 때가 많고, 밖에서 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 final 클래스보다 더 유연하다. 패키지 밖에서는 사실상 final이다.

public이나 protected 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는게 불가능하기 때문이다.

유연성과 더불어 다음 릴리즈에서 객체 캐싱 기능을 추가해 성능을 올릴 수도 있다.

 

 

 

불변으로 설계되지 않았던 객체

---

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

그래서 이 두 클래스의 메소드들은 모두 재정의할 수 있게 설계되었고, 하위 호환성이 발목을 잡아 지금까지 문제를 고치지 못했다.

 

그러니 만약 신뢰할 수 없는 클라이언트로부터 BigInteger나 BigDecimal의 인스턴스를 인수로 받는다면 주의해야한다.

인수로 받은 객체가 불변이어야 클래스의 보안을 지킬 수 있다면, 신뢰할 수 없는 가변 하위 클래스가 들어올 수 있다고 가정하고

방어적으로 복사해 사용해야한다.

 

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

 

 

불변 클래스의 규칙 완화

---

"어떤 메소드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다" 를 조금 완화할 수 있다.

 

어떤 불변 클래스는 계산 비용이 큰 값을 나중에(처음 쓰일 때) 계산하여 final이 아닌 필드에 캐시해놓기도 한다.

똑같은 값을 다시 요청하면 캐시해둔 값을 반환해 계산 비용을 절감하는 것이다. 순전히 객체가 불변이기에 할 수 있다.

몇번을 계산해도 항상 같은 결과가 만들어짐이 보장되기 때문이다.

 

아이템11 phoneNumber의 hashCode메소드를 처음 불렀을때 해시값을 계산해 캐시,

지연 초기화의 예이기도 한 이 기법은 String도 사용한다.

 

 

직렬화할 때 주의점

---

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

 

 

 

정리

---

1. getter가 있다고 해서 무조건 setter를 만들지는 말자. 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
2. 무거운 값 객체가 성능때문에 어쩔 수 없다면 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하자
3. 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
4. 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
5. 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.

이상의 원칙을 잘 방증한 예: java.util.concurrent 패키지의 CountDownLatch class

가변 클래스지만, 가질 수 있는 상태의 수가 많지 않다. 카운트가 0이되면 더는 재사용 할 수 없을 것이다.

 

 

 

* 위 글은 EffectiveJava 3/E 책 내용을 정리한 글로, 저작권 관련 문제가 있다면 댓글로 남겨주시면 즉각 삭제조치 하겠습니다.