[이펙티브 자바] 변경 가능성을 최소화하라 ─ 4장:클래스와 인터페이스:Item17

  불변 클래스

 

불변 클래스는 내부 값을 수정할 수 없는 클래스다. 즉 불변 인스턴스에 간직된 정보는 고정되어, 객체가 파괴되는 순간까지 절대 변하지 않는다. 또한 불변 클래스는 가변 클래스보다 설계, 구현, 사용이 쉬우며, 오류의 여지가 적어 안전하다. 자바에서도 다양한 불변 클래스가 있는데, String, BigInteger, BigDecimal이 있다.

 

.

.

 

─ 불변 클래스가 따르는 5가지 규칙

 

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

 

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

- 하위 클래스에서 실수로, 악의로 객체의 상태를 변하게 하는 사태를 막아야 함

- 상속을 막는 대표적인 방법은 final 클래스로 선언하는 것이고, 다른 방법도 뒤에서 언급할 것임

 

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

- final은 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장함

 

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

- 기술적으로는 기본타입 필드나 불변객체를 참조하는 필드를 public final로만 선언해도 불변 객체가 되지만, 그러면 다음 릴리즈에서 내부 표현을 바꾸지 못하므로 권하지 않음

 

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

- 절대 클라이언트가 객체 참조를 가리키게 해서는 안됨

- Getter가 절대 그 필드를 그대로 반환하게 두면 안됨

- 반드시 생성자, Getter, readObject 메서드 모두에서 방어적 복사를 수행해야 함

 

 

---

  불변 객체의 장점

불변 객체의 장점 및 특징을 나열해보자.

 

■ 불변 객체는 단순하다

- 불변 객체는 생성된 시점의 상태를 객체가 파괴될 때까지 그대로 간직한다. 모든 생성자가 클래스 불변식을 보장한다면, 그 클래스를 사용하는 개발자가 노력하지 않아도 영원히 불변이다.

- 반면 가변 객체는 언제든 임의의 복잡한 상태에 놓을 수 있다. 믿고 사용하기 어려울 수도 있다.

 

■ 불변 객체는 근본적으로 thread-safe하여 따로 동기화할 필요 없다

- 사실 클래스를 thread-safe하게 만다는 가장 쉬운 방법이기도 하다.

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

 

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

- 불변 객체에 대해서는 그 어떠한 스레드도 다른 스레드에 영향을 줄 수 없다.

 

문제가 없으므로, 한번 만든 인스턴스를 최대한 재활용하기를 권장한다.

가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것이다.

// 예시: 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);

 

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

 

불변 객체를 자유로이 공유할 수 있다는 점은 방어적 복사(Item50)도 '필요 없다'는 결론을 이끈다. 아무리 복사해도 원본과 똑같으니 의미가 없는 셈이다. 그러니 불변 클래스는 clone 메서드나 복사 생성자(Item13)를 제공하지 않는 것이 좋다. 다만 기존 자바의 String 클래스의 복사 생성자는 이 사실을 잘 이해하지 못한 자바 초창기때 만들어진 것으로 사용을 지양해야 한다(Item6)

 

■ 불변 객체끼리는 내부 데이터를 공유할 수 있다

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

 

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

- 그 객체의 구조가 아무리 복잡하더라도 불변식을 유지하기 아주 수월하기 때문이다.

좋은 예로 불변 객체는 Map의 키와 Set의 원소로 쓰기 안성맞춤이다.

Map이나 Set은 안에 담긴 값이 바뀌면 불변식이 허물어지는데, "불변 객체를 사용하면 그런 걱정 X"

 

■ 불변 객체는 그 자체로 실패 원자성을 제공한다(Item76)

- 상태가 절대 변하지 않으니, 잠깐이라도 불일치 상태에 빠질 가능성이 없다.

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

 

 

 

---

  불변 객체의 단점

 

■ 값이 다르면 반드시 독립된 객체로 만들어야 한다

값의 가짓수가 많다면 이들을 모두 만들 때 큰 비용이 들 것이다.

 

불변 클래스 BigInteger를 예를 들어서, 다음 상황을 생각해보자.

"백만 비트짜리 BigInteger에서 비트 하나를 바꿔야 함"

 

즉 원본과 단지 한 비트만 달라진다. 그러나 BigInteger는 불변 클래스이기 때문에 다시 백만 비트짜리 인스턴스를 생성해야 하는 것이다. 시간과 공간을 잡아먹는 것이다.

아래 코드에서 flipBit 메서드는 새로운 BigInteger 인스턴스를 생성한다. 

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

 

이러한 상황에서 "가변 클래스"는 가변이라는 특징 때문에 위와 같은 문제가 없다.

BigSet도 임의 길이의 비트 순열을 표현하지만, BigSet은 '가변'이다.

이 BigSet 클래스는 원하는비트 하나만 '상수 시간'안에 바꿔주는 메서드를 제공한다.

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

 

 

---

  가변 동반 클래스

 

만약 원하는 객체를 완성하기까지 많은 단계를 거쳐야 하고, 중간 단계의 객체들은 필요가 없다면 성능 문제가 커질 것이다.  대처 방안은 다음과 같다.

 

 

흔히 쓰일 것 같은 다단계 연산(multistep operation)을 예측하여 기본 기능으로 제공하는 방법이다. 이러한 다단계 연산을 기본으로 제공한다면 단계마다 객체를 생성하지 않아도 된다. 불변 객체는 이것을 효과적으로 내부적으로 구현할 수 있다.

→ 자바의 String 클래스가 예시다. String의 가변 동반 클래스는 StringBuilder다.

→ BigInteger는 모듈러 지수 같은 다단계 연산 속도를 높여주는 '가변 동반 클래스(companion class)를 package-private으로 두고 있다. 이 가변 동반 클래스를 사용하기는 BigInteger를 사용하는 것보다 훨씬 어렵지만, BigInteger가 다 알아서 처리해준다.

→ 클라이언트가 원하는 복잡한 연산들을 정확히 예측할 수 있다면 package-private의 가변 동반 클래스만으로 충분하다. 그렇지 않다면 이 클래스를 public으로 제공하는 게 최선이다.

 

 

---

  불변 클래스 설계하기 by 정적 팩터리 메서드

 

불변 클래스의 규칙을 상기하고 가자.

─ 불변 클래스의 5가지 규칙 ─

1. 객체의 상태를 변경하는 Setter를 제공하지 않는다.
2. 클래스를 확장할 수 없도록 한다. (상속 막기)
3. 모든 필드를 final로 선언한다.
4. 모든 필드를 private으로 선언한다.
5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

 

일단 클래스를 확장할 수 없도록 하기 위해 "상속을 막아야 한다"

가장 쉬운 방법으로는 final 클래스로 선언하는 방법일 것이다. 그러나 더 유연한 방법도 있다.

 

모든 생성자를 private 혹은 package-private으로 만들고, public 정적 팩터리 메서드를 제공하는 방법이다(Item1).

아래 코드가 그렇다. 이 방법이 최선일 때가 많다.

생성자가 public, protectd가 아니기 때문에 다른 패키지에서는 이 클래스를 확장(상속)할 수 없다.

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

 

패키지 바깥의 클라이언트에가 바라본 이 불변 객체는 사실상 final이다.

그리고 바깥에서는 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 훨씬 유연하다. 

 public이나 protected 생성자가 없으므로, 다른 패키지에서는 이 클래스를 확장하는 것이 불가능하다. 

또한 정적 팩터리(Item1)의 장점들도 누릴 수 있다. 이를테면 정적 팩터리 메서드와 캐싱구조를 함께 사용하면 매번 새로운 객체를 생성할 필요가 없어진다거나. 

 

.

.

 

 

■ BigInteger, BigDecimal의 설계 실수

 

두 클래스 설계 당시엔 불변객체가 사실상 final이어야 한다는 생각이 널리 퍼지지 않았다.

그래서 확장(상속) 가능하며, 메서드들이 모두 재정의할 수 있게 설계되었고, 지금까지 문제가 있다.

 

그래서 주의해야 한다!

신뢰할 수 없는 곳에서 BigInteger, BigDecimal 타입인 파라미터를 받는다면 주의해야 한다. 즉 파라미터로 들어온 객체가 '진짜' BigInteger, BigDecimal인지 반드시 확인해야 한다. 만약 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면, 이 인수들은 가변이라고 가정하고 방어적으로 복사해 사용해야 한다(Item50).

예를 들면 아래 코드처럼..

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

 

 

 

---

  불변 클래스의 모든 필드는 final

 

∨ 불변 클래스가 따르는 규칙을 보면 "모든 필드를 final로 선언하라"는 규칙이 있으며, 어떠한 메서드도 그 객체를 수정할 수 없게 한다. 그러나 성능을 위해 이렇게 완화할 수 있다.

"어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다"

 

 

∨  어떤 불변 클래스는 계산 비용이 큰 값을 나중에(처음 쓰이는 시점에) 계산하여 final이 아닌 필드에 캐시해놓기도 한다. 이 방법은 해당 클래스가 불변이기 때문에 가능한데, 계산시 항상 같은 결과가 만들어짐이 보장되기 때문이다.

예를 들어 다음 PhoneNumber의 hashCode 메서드는 처음 불렸을 때 해시 값을 계산해 캐시해둔다.

동시에, 지연 초기화를 참고하자(Item84)

private final class PhoneNumber {
    private final short areaCode, prefix, lineNum;
    
    ...
    
    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 * Short.hashCode(lineNum);
            hashCode = result;
        }
        return result;
    }

    ...
}

 

 

---

  정리

 

- 클래스는 최대한 불변이어야 한다.

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

* java.util.Date와 java.awt.Point도 원래 불변이어야 하지만 그렇지 않게 만들어졌다.

* String과 BigInteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 고심해야 한다. 성능 때문에 어쩔 수 없다면(Item67) 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자.

 

- 불변으로 만들 수 없더라도, 변경할 수 있는 부분을 최소화하자.

: 객체는 예측하기 쉬워야하고 오류가능성을 줄여야한다.

: 꼭 변경해야 할 필드를 뺀 나머지 모두를 final로 선언하자.

 

- "합당한 이유가 없다면 모든 필드는 private final이어야 한다"

 

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

: 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안된다.

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

 

 

위 원칙들을 잘 지킨 가변 클래스의 예시는 java.util.concurrent 패키지의 CountDownLatch 클래스다. 가변 클래스더라도 상태의 가지수가 많지 않다. 또한 인스턴스를 생성해 한 번 사용하고 그걸로 끝이다. 카운트가 0에 도달하면 더는 재사용 불가한 것이다.

 

 

 

---

  기타 언급사항

이번 설명에서 Complex 클래스에 대한 주의를 하자면, 이 클래스는 불변을 설명하기 위한 예시일 뿐 실무에서 사용할 수준이 안된다. 반올림을 제대로 처리하지 않고 복소수 NaN과 무한대도 다루지 못한다.