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

클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다. 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다.

 

이번 장에서는 변경 가능성을 최소화하기 위해 클래스를 불변으로 만들기 위한 규칙과, 불변클래스의 장점, 불변클래스의 예 등을 다룹니다

 

KEY WORD: 정적 펙터리 메서드(static factory method), fianl 

---

불변 클래스 

불변 클래스란

인스턴스의 내부 값을 수정할 수 없는 클래스로 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다.

 

불변 클래스 만들기 위한 법칙

클래스를 불변으로 만들려면 다음 다섯가지 규칙을 따르면 됩니다.

• 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.
• 클래스를 확장(상속)할 수 없도록 한다.
  • 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 사태를 막아준다.
• 모든 필드를 final로 선언한다. 
  • 시스템이 강제하는 수단을 이용해 설계자의 의도를 드러내는 방법이다.
• 모든 필드를 private로 선언한다. 
  • 필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아준다.
• 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 
  • 클래스에 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야 한다. 
  •  접근자 메서드가 해당 필드를 그대로 반환해서도 안 되며, 방어적 복사를 수행해야 한다.

 

불변 클래스의 예

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 complex) {
        return new Complex(re + complex.re, im + complex.im);
    }

    // ...

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Complex complex = (Complex) o;
        return Double.compare(complex.re, re) == 0 && Double.compare(complex.im, im) == 0;
    }

    @Override
    public int hashCode() {
        return Objects.hash(re, im);
    }
}

 

• 위의 사칙연산 메서드를 보면  자신을 수정하지 않고 새로운 Complex 인스턴스를 만들어서 반환한다.
• 이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라고 한다.
• 함수형 프로그래밍에 익숙하지 않다면 조금 부자연스러워 보일 수도 있지만, 이 방식으로 프로그래밍하면 코드에서 불변이 되는 영역의 비율이 높아지는 장점이 있다.

 

 

불변 클래스의 장점

불변 객체는 단순하다

• 불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다.
• 가변 객체는 임의의 복잡한 상태에 놓일 수 있기 때문에  믿고 사용하기 어렵다.

 

근본적으로 스레드 안전하여 동기화 할 필요가 없다

• 여러 스레드가 동시에 사용해도 절대 훼손되지 않는다.
• 불변 클래스는 클래스를 thread safe 하게 만드는 가장 쉬운 방법이기도 하다.

 

불변객체는 안심하고 공유 가능

• 불변 객체에 대해서는 그 어떤 스레드에 영향을 줄 수 없다.
• 아무리 복사해봐야 원본과 똑같아 방어적 복사가 필요 없으므로, clone 메서드나 복사 생성자를 제공하지 않는 게 좋다.
• 같은 맥락에서 String 클래스는 불변 객체이므로 복사 생성자는 되도록 사용하지 말 것

 

한번 만든 인스턴스 최대한 재활용

• 자주 사용되는 인스턴스를 캐싱해 메모리 사용량과 가비지 컬렉션 비용을 줄인다.
• 자주 쓰이는 값들을 상수로 제공하여 캐싱할 수 있다. (ex. BigInteger, Wrapper class 같이 박싱 된 기본 타입 클래스 전부) 
• public 생성자 대신 정적 팩토리를 제공하여 캐싱하면 클라이언트 수정이 없이 필요에 따라 캐시 기능을 덧붙일 수 있다.

 

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

• BigInteger 클래스는 부호(sign)와 크기(magnitude)를 따로 표현한다. (부호- int변, 크기-int배열)
• 크기는 같고 부호만 반대로 표현하는 negate 메서드는 새로운 BigInteger를 생성하는데, 이때 가변인 배열을 복사하는 대신 원본 인스턴스와 공유한다.
• 따라서 새로운 인스턴스는 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.

//negate 메서드
public BigInteger negate() {
        return new BigInteger(this.mag, -this.signum);
}

 

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

Map과 Set은 값이 바뀌지 않는 구성요소들(keySet, elements)로 이루어져 있다. 이러한 상황에서 불변 객체를 사용하면 안에 담긴 값이 바뀔 일이 없어 적합하다.

 

 

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

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

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

 

불변 클래스의 단점

 

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

• 예를 들어, 100만 비트자리 BigInteger 에서 비트 하나를 바꿔야 한다고 가정하면 너무 큰 비용을 처리해야 한다.

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

 

이에 대처하는 방안은 두 가지이다. 

• 첫 번째는 흔히 쓰일 다단계 연산(multistep operation)들을 예측하여 기본 기능으로 제공하는 방법이다.
  
  • 클라이언트가 원하는 복잡한 연산들을 정확히 예측할 수 있다면 이러한 다단계 연산 속도를 높여주는 package-private인 가변 동반 클래스(companion class)만으로도 충분하다.
• 예측이 불가능하다면 가변 동반 클래스를 public으로 제공하는 게 최선이다. 대표적인 예로 StringBuilder, StringBuffer가 있다..

 

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

위에서 클래스가 불변임을 보장할려면 자신을 상속하지 못하게 해야 함을 설명하였다. 자신을 상속하지 못하게 하는 가장 쉬은 방법은 fianl 클래스로 선언하는 것이지만 모든 생성자를 private로 만들고 public 정적 팩토리 메서드를 통해 객체를 생성하는 방법이 더 유연한 방법이다. 

 

아래는 위 Complex 클래스 예제를  <모든 생성자를 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 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 훨씬 유연하다
• public이나 protected 생성자가 없으니 다른 패키지에서 이 클래스를 확장하는 게 불가능하기 때문에 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다
• 정적 팩토리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이후에 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.

 

핵심 정리

클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.

• PhoneNumber와 Complex 같은 단순한 값 객체는 불변으로 만들도록 하자.
• 성능 때문에 어쩔 수 없다면 불변 클래스와 함께 가변 동반 클래스를 public 클래스로 제공하도록 하자.

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

• 꼭 변경해야 하는 필드를 제외한 나머지 모두를 final로 선언하도록 하자. 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.

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

• 확실한 이유가 없다면 생성자나 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공하면 안 된다.
• 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안 된다. 복잡성만 커지고 성능 이점은 거의 없다.