[이펙티브 자바] 아이템17 | 변경 가능성을 최소화하라

불변 클래스

인스턴스 내부 값을 수정할 수 없는 클래스를 말한다. 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 달라지지 않는다. 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며 오류가 생길 여지가 적다.

자바 라이브러리에는 String, 기본 타입 박싱 클래스, BigInteger, BigDecimal 등 다양한 불변 클래스가 존재한다.

불변 클래스의 장점

• 가변 클래스를 이용한다면 인스턴스가 사용되는 곳에 데이터 검증작업이 이루어져야한다. 하지만, 불변 클래스를 이용한다면 클래스 내부의 데이터가 안전하다는 것이 보장되기 때문에 데이터 검증작업이 필요없다.

불변 클래스 작성 규칙

• 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.
• 클래스를 확장할 수 없도록 한다.
  • 하위 클래스에서 객체의 상태를 변하게 만드는 것을 막아준다.
  • 상속을 막는 대표적인 방법으로 final로 선언하는 것이 있다.
• 모든 필드를 final로 선언한다.
  • 시스템이 강제하는 수단을 이용해 설계자의 의도를 드러내는 방법이다.
  • 새로 생성된 인스턴스를 동기화과정 없이 다른 스레드에서도 동작하는것을 보장한다.
• 모든 필드를 private으로 선언한다.
  • 필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 것을 막아준다.
  • 불변 객체를 참조하는 필드를 public final로만 선언해도 불변 객체가 되지만 이렇게 하면 다음 릴리스에서 내부 표현을 변경하지 못하는 상태가 된다.
• 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.
  • 클래스에 가변객체를 참조하는 필드가 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야한다. 이런 필드는 클라이언트가 제공한 객체 참조를 가리키면 안되며, 접근자 메서드가 그 필드를 그대로 반환해서도 안된다. 생성자, 접근자 readObject 메서드 모두에서 방어적 복사를 수행하는게 좋다.

함수형 프로그래밍을 이용한 불변 클래스

[불변 복소수 클래스]

public class Complex {
    private final double re;
    private final double im;

    public Complex(final double re, final double im) {
        this.re = re;
        this.im = im;
    }
    
    public double realPart(){
        return re;
    } // 실수부
    
    public double imaginePart(){
        return im;
    } // 허수부
    
    public Complex plus(Complex complex){
        return new Complex(re + complex.re, im + complex.im);
    }

    public Complex minus(Complex complex){
        return new Complex(re - complex.re, im - complex.im);
    }

    public Complex times(Complex complex){
        return new Complex(re * complex.re - im * complex.im, re * complex.im - im * complex.re);
    }

    public Complex divideBy(Complex complex){
        double temp = complex.re * complex.re + complex.im + complex.im;
        return new Complex((re*complex.re + im * complex.im) / temp, (im * complex.re - re * complex.im) / temp);
    }
}
...

위 코드의 사칙연산 메서드들은 인스턴스 자신을 수정하지 않고 새로운 Complex 인스턴스를 만들어 반환한다. 이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다.

또한 메서드 이름으로 (add 같은) 동사가 아닌 (plus 같은) 전치사를 사용한 이유는 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 이유이다.

이같은 함수형 프로그래밍과 달리, 절차적, 혹은 명령형 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.

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

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

• 불변 객체에 대해서는 어떤 스레드도 다른 스레드에 영향을 주지 않기 때문에 안심하고 객체를 공유할 수 있다.

• 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하는것이 좋다.

• 대표적인 재활용 방법으로 상수(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);

불변 클래스와 정적 팩토리

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

• 정적 팩토리를 사용하면 클라이언트들이 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.

• 새로운 클래스를 설계할 때 정적 팩토리를 만들어두면 클라이언트를 수정하지 않고 필요에 따라 캐시 기능을 덧붙일 수 있다.

불변 클래스는 방어적 복사가 필요 없다.

불변 클래스를 아무리 복사해봐야 원본과 똑같기 때문에 복사 자체가 의미가 없다.

따라서 불변 클래스는 clone 메서드나 복사 생성자를 제공하지 않는게 좋다.

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

public class BigInteger extends Number implements Comparable<BigInteger> {
    final int signum; // 값의 부호
    
    final int[] mag; // 값의 크기
    
    ...
    
     public BigInteger negate() {
        return new BigInteger(this.mag, -this.signum);
    }
    ...

BigInteger 클래스의 negate 메서드는 크기가 같고 부호만 반대인 새로운 BigInteger를 생성한다. 이 때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 된다. 그 결과 새로 만든 BigInteger 인스턴스도 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.

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

값이 바뀌지 않는 구성요소들로 객체를 구성하면 구조가 복잡해도 불변식을 유지하기 수월하다.

좋은 예시로, 불변 객체는 맵의 키와 집합(Set)의 원소로 쓰기에 안성맞춤이다. 맵과 집합은 안에 담긴 값이 바뀌면 불변식이 허물어지기 때문이다.

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

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

불변 객체는 상태가 바뀌지 않아 불일치 상태에 빠지지 않기 때문에 실패 원자성을 제공한다고 볼 수 있다.

불변 클래스의 단점

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

값의 가짓수가 많다면 이들을 모두 불변 객체로 만들어야하기 때문에 큰 비용을 치뤄야 한다. 예로 BigInteger의 flipBit 메서드와 BitSet의 flip 메서드가 있다.

1,000,000 비트짜리 BigInteger에서 비트 하나를 바꿔야한다고 가정해보자.

[BitInteger의 flipBit]

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

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

이런 메서드들은 원하는 객체를 완성하기까지의 단계가 많고 중간 단계에서 만들어진 객체들이 버려지게 된다면 성능문제가 발생할 수 있다. 이런 문제를 해결하기 위한 방법에는 두가지가 있다.

☑️ 첫 번째, 가변 동반 클래스 제공.

흔하게 쓰일 다단계 연산을 예측하여 기본 기능으로 제공한는 것. BigInteger는 지수 연산같은 다단계 연산시 발생하는 불변 클래스의 문제점을 보완하기 위해 다단계 연산들을 묶음으로 제공하는 클래스를 제공한다.

실제 BigInteger 클래스가 포함된 Math 패키지를 살펴보면 아래와 같이 package-private 형태로 클래스들을 제공하고 있다. 이 클래스들을 가변 동반 클래스라고 한다.

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

☑️ 두 번째, 가변 동반 클래스와 불변클래스를 public으로 제공.

클라이언트들이 원하는 복잡한 연산을 예측할 수 없다면 클래스를 public으로 제공하는 것이 좋다.

자바 플랫폼 라이브러리에서 이에 해당하는 대표적인 경우로 String 클래스가 있다. String의 가변 동반 클래스는 바로 StringBuilder다.

가변 동반 클래스

불변 클래스와 거의 동일한 기능을 가지고 있지만 가변적인 클래스를 말한다.

가변 동반 클래스는 주로 불변 클래스가 비즈니스 로직 연산 등 시간 복잡도가 높은 연산시 불필요한 클래스 생성을 막기위해 내부적으로 사용한다.

대표적으로 불변클래스인 String에게 가변 동반 클래스 StringBuilder가 있다.

불변 클래스를 만드는 여러방법

• final 클래스로 선언
• 모든 생성자를 private 혹은 package-private으로 설정하고 public정적 팩터리 제공

[public 정적 팩토리를 이용한 불변 클래스 작성]

public class Complex {
    private final double re;
    private final double im;

    private Complex(final double re, final double im) {
        this.re = re;
        this.im = im;
    }

    public static Complex valueOf(double re, double im) {
        return new Complex(re, im);
    }
    ... // 코드생략
}

클라이언트에서 바라보는 이 패키지는 사실상 final 이다. public 이나 protected 생성자가 없으니 다른 패키지에서 이 클래스를 확장하는것이 불가능하기 때문이다.

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

BigInteger와 BigDecimal의 인스턴스를 인수로 받을 때 주의해야 한다.

BigInteger와 BigDecimal은 메서드들을 모두 재정의할 수 있게 설계되었다. 따라서 신뢰할 수 없는 클라이언트로부터 BigInteger나 BigDecimal의 인스턴스를 인수로 받는다면 객체가 진짜인지 확인해야 한다.

신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면 이 인수들을 가변이라고 가정하고 방어적으로 복사해 사용해야 한다.

[인스턴스 인수 확인 후 방어적 복사여부 결정]

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

[정리]

• 클래스는 꼭 필요한 경우가 아니면 불변이여야 한다.
  • getter 가 있다고 setter 를 만들지 말자
  • 단순한 값 객체는 항상 불변으로, BigInteger나 String 같은 무거운 값 객체도 불변으로 만들거나 성능이슈로 불변으로 만드는것이 불가능하다면 가변 동반 클래스를 public 클래스로 제공하도록 하자.
    
    
• 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자
  • 객체가 가질 수 있는 상태수를 줄이면 객체를 예측하기 쉬워지고 오류가능성이 줄어든다. 그러니 꼭 변경해야 할 필드를 제외하고 나머지 모든 필드는 private final 이어야 한다.
    
    
• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
  • 확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 메서드도 public으로 제공해서는 안된다.
    (객체 재활용을 목적으로 상태를 다시 초기화하는 메서드도 안된다.)

[Reference]
현구막 기술블로그
bearstark