Item17 : 변경 가능성을 최소화하라

불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스를 말한다. 불변 클래스가 가지고 있는 정보는 고정되어 객체가 없어지는 순간까지 절대 달라지지 않는다. 자바 라이브러리에서 가장 대표적인 불변 클래스가 String, primitve 타입의 박싱 된 클래스, BigIntegner, BigDecimal 등이 있다.

불변 클래스는 다음과 같은 장점이 있다. 바로 구현하고 사용하기 쉬우며, 오류가 생길 여지가 적어 훨씬 안전하다. 그럼 어떻게 불변을 만들지 알아보자.

 

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

클래스를 불변으로 만들려면 다음과 같이 5가지의 규칙을 따라야 한다.

1. 객체의 상태를 변경하는 메서드를 제공하지 않는다.
2. 클래스를 확장할 수 없도록 한다. ( 나쁜 의도로 객체의 상태를 변하게 만드는 사태를 막아주기 위해 )
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); // 새로운 Complex를 반환 -> 불변을 보장 -> 함수형 프로그래밍
  }

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

이 복소수 예제에서 가장 중요한점은 Complex 인스턴스를 만들어 반환하는 사칙연산 메서드이다. 피연산자에 함수를 적용해 그 결과를 반환하지만, 그 자체는 그대로인 프로그래밍을 했다. 즉 이 프로그래밍 패턴을 함수형 프로그래밍이라 한다.

만약 절차적 혹은 명령형 프로그래밍으로 하게 된다면 메소드에서 피연산자인 자신을 수정해 자신의 상태가 변할 것이다. 그리고 전치사를 사용한 점에서도 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조해준다.

 

불변 객체의 장단점

함수형 프로그래밍이 익숙하지 않으면 위의 코드가 조금 부자연스러워 보일 수 있다. 하지만 이 방식으로 프로그래밍하면 코드에서 불변이 되는 영역의 비율이 높아지는 장점을 누릴 수 있다. 그렇다면 불변이 어떤 부분에서 장점을 주는지 한번 보자.

1. 불변 객체는 단순하다

불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다. 모든 생성자가 클래스 불변식을 보장한다면 그 클래스를 사용하는 프로그래머가 다른 노력을 들이지 않더라도 영원히 불변으로 남는다. 즉 사용자가 내부 컴포넌트를 신경 안 써도 되어 믿고 사용할 수 있다.

2. 불변 객체는 근본적으로 Thread-Safe하여 따로 동기화할 필요가 없다.

불변 객체로 만들면 여러 쓰레드가 동시에 사용해도 절대 훼손되지 않는다. 또한 불변 객체가 Thread-Safe에 있어서 가장 쉬운 방법이기도 하다. 정리하자면 불변 객체에 대해서는 그 어떤 쓰레드도 다른 쓰레드에게 영향을 줄 수 없으니 불변 객체는 안심하고 공유할 수 있다.

따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권한다. 가장 쉬운 재활용 방법은 상수를 제공하는 것이다.

• 복소수의 상수 예제

public static final Complex ZERO = new Complex(0,0);

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

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

인스턴스에 가변을 가진 컴포넌트가( 배열값 ) 있어도 불변으로 만들면 새로운 인스턴스를 생성할 때, 복사하지 않고 원본 인스턴스와 공유해도 된다. 그 이유는 값이 바뀔 일이 없기 때문에 안전하게 사용이 가능하다.

즉 불변 객체를 자유롭게 공유할 수 있다는 점이 방어적 복사도 필요 없다는 결론이 나오게 된다. 아무리 복사해봐야 원본과 똑같기 때문에 복사 자체가 의미가 없다. 그러니 불변 클래스는 clone 메소드나 복사 생성자를 제공하지 않는 게 좋다. 특히 String 클래스는 불변 클래스이기 때문에 String 클래스의 복사 생성자를 사용하면 안 된다.

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

값이 바뀌지 않는 구성요소들로 이뤄진 객체라면 그 구조가 아무리 복잡하더라도 불변식을 유지하기 수월하다. 예를 들어 불변 객체는 Map의 키와 List의 원소로 쓰기에 좋고 바뀔 걱정도 안 해도 된다.

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

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

 

여기까지 불변 객체의 장점을 보았다. 그러면 불변객체의 단점이 뭐가 있을까? 바로 다음과 같다.

1. 불변객체의 값이 다르면 반드시 독립된 객체로 만들어야 한다.

값이 가짓수가 많다면 이들을 모두 만들어야 한다. 이는 새로운 값을 모두 만든다는 의미이고 그만큼 큰 비용을 치러야 한다는 얘기이다. 즉 새로운 객체를 만듦으로써 자원 소모가 많아지게 되고 성능 저하를 일으키며 코드의 재사용성까지 떨어지게 된다.

또한 원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어지는 객체들이 모두 버려진다면 성능 문제가 더 불거진다. 그래서 이 문제에 대한 대처 방법은 다음과 같이 2가지로 볼 수 있다.

첫 번째로는 다단계 연산들을 예측하여 기본 기능으로 제공하는 방법이다. 이러한 다단계 연산을 기본으로 제공한다면 더 이상 각 단계마다 객체를 생성하지 않아도 된다. 예를 들어 BigInteger 같은 경우 모듈러 지수 같은 BigDecimal를 package-private로 두어 연산 속도를 높여주고 있다.

두 번째로는 다단계 연산을 쉽게 예측할 수 없다면 가변 동반 클래스를 public 클래스로 제공한다. 대표적인 예로 String 클래스의 동반 클래스인 StringBuilder, StringBuffer를 들 수 있다.

 

불변 클래스의 설계 방법

상속하지 못하게 하는 방법은 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);
    }

    ...
}

이 방식을 사용하면 바깥에서 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 훨씬 유연한다. 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다. public 생성자나 protected 생성자가 없으니 말이다. 이와 같이 정적 팩토리 메소드 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이에 더해 다음 릴리스에 객체 캐싱 기능을 추가해 성능을 끌어올릴 수 도 있다.

또한 매개변수에서 신뢰할 수 없는 하위 클래스의 인스턴스라고 생각하면, 해당 매개변수들은 가변이라 가정하고 방어적으로 복사해 사용해야 한다. 예를 들면 다음과 같다.

• 신뢰할 수 없는 매개변수의 대처

public static BigInteger safeInstance(BigInteger val) { // 신뢰할 수 없는 하위 인스턴스라 판단하면
    return val.getClass() == BigInteger.class ?    // 여기서 한번 더 검증하고
        val : new BigInteger(val.toByteArray()); // true 면 그대로 반환, false면 새로운 인스턴스 생성후 반환
}

앞 규칙에 따르면 모든 필드가 final이고 어떤 메서드도 그 객체를 수정할 수 없어야 한다. 사실 이 규칙은 좀 과한 감이 있어서, 성능을 위해 다음처럼 살짝 완화 할 수 있다.

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

즉 어떤 불변 클래스는 계산 비용이 큰 값을 나중에 계산하여 final이 아닌 필드에 캐시 해 놓기도 한다. 똑같은 값을 다시 요청하면 캐시 해둔 값을 반환하여 계산 비용을 절감하는 것이다. 이는 그 객체가 순전히 불변이기 때문에 몇 번을 계산해도 항상 같은 결과값을 보장한다.

 

정리

클래스가 꼭 필요한 것이 아니라면 불변으로 만드는 것이 좋기 때문에 setter를 만들지 않는 것이 좋다. 불변 클래스는 장점이 많으며, 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐이다.

그렇기 때문에 단순한 값이나 무거운 객체는 항상 불변으로 만들자. 그리고 성능 때문에 어쩔 수 없다면 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자.

한편 모든 클래스를 불변으로 만들 수 없기 때문에 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자. 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다. 그러니 웬만하면 final로 선언하자. 또한 다른 합당한 이유가 없다면 외부 접근을 최소화해주는 private로 선언하자. 즉 private final로 선언해 모든 필드들을 불변으로 만드는 것이 좋다.

마지막으로 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다. 확실한 이유가 없다면 생성자와 정적 팩토리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안된다. 객체를 재활용할 목적으로 상태를 다시 초기화하는 메소드도 안된다. 복잡성만 커지고 성능 이점은 거의 없다.