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

1. 불변 클래스란?

인스턴스의 내부 값을 수정할 수 없는 클래스!

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

 

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

2. 불변 클래스를 만들기 위한 규칙

1) 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.

 

2) 클래스를 확장할 수 없도록 한다. (extend X)

 

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

 

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

 

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

 

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

- 기술적으로는 public final로만 선언해도 불변 객체가 되지만, 이렇게 하면 다음 릴리스에서 내부 표현을 바꾸지 못한다.

 

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

 

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

- 접근자 메서드가 그 필드를 그대로 반환해서는 안된다. (생성자, 접근자, readObject 메서드에서 방어적 복사 수행)

위 메서드들은, 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어서 반환한다.

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

3. 불변 객체의 장점

1) 불변 객체는 단순하다

불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다.

모든 생성자가 클래스 불변식을 보장한다면 그 클래스를 사용하는 프로그래머가 다른 노력을 들이지 않아도 영원히 불변으로 남는다.

 

반면 가변 객체는 임의의 복잡한 상태에 놓일 수 있다.

(변경자 메서드가 일으키는 상태 메서드를 제대로 문서화 해두지 않는다면 믿고 사용하기 어려울 수 있다)

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

여러 스레드가 동시에 사용해도 절대 훼손되지 않는다. (Thread-safe하게 만드는 가장 쉬운 방법)

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

 

따라서 불변 클래스는 한번 만든 인스턴스를 최대한 재활용하는 걸 추천한다.

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

정적 팩터리를 사용하면, 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 GC 비용이 줄어든다.

3) 방어적 복사도 필요 없다

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

따라서 clone 메서드, 복사 생성자를 제공하지 않는 게 좋다.

(String 클래스의 복사 생성자 사용은 지양해야 한다)

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

BigInteger 클래스의 mag 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유하고 있다.

그 결과 새로 만든 BigInteger 음수 인스턴스도 원본 인스턴스가 가리키는 mag 배열을 그대로 가리킨다.

 

불변 인스턴스는 내부 값이 바뀌지 않음이 보장되기 때문에 가능한 일이다.

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

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

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

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

4. 불변 객체의 단점

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

BigInteger 클래스의 flipBit 메서드는 매번 새로운 인스턴스를 생성한다. (O(N))

따라서 만약 기존 값이 백만 비트짜리였다면, 비트 하나를 바꾸기 위해 큰 비용을 낭비하게 된다.

 

따라서 원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 이슈가 생긴다.

해결방법은 아래와 같다.

1) 다단계 연산들을 예측하여 기본 기능으로 제공

다단계 연산 속도를 높여주는 가변 동반 클래스를 package-private으로 둔다.

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

BitSieve, MutableBigInteger, SignedMutableBigInteger 와 같은 가변동반 클래스를 직접 사용하려면 더 어렵기 때문에 BigInteger 클래스 내부에서 사용하고 있다.

2) 다단계 연산을 정확히 예측할 수 없다면, public 가변 동반 클래스 제공

클라이언트들이 원하는 복잡한 연산들을 정확히 예측할 수 없다면, 해당 클래스를 public으로 제공하는 게 최선이다.

StringBuilder sb = new StringBuilder();
sb.append("문자열 추가");
String result = sb.toString();
System.out.print(result);

 

 

대표적인 예시는, String의 가변 동반 클래스 StringBuilder이다.

불변클래스인 String을 계속 생성해서 추가하는게 아니라, StringBuilder의 도움을 받아서 효과적으로 문자열을 조작한다.

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

1) final 클래스로 선언

 

2) 모든 생성자를 private(또는 package-private)으로 선언 + public 정적 팩터리 제공

public class Complex {
  private fianl 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이다.

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

다수의 구현 클래스를 활용한 유연성을 제공하고, 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.

6.  BigInteger, BigDecimal 설계시 주의점

이 두 클래스의 메서드가 모두 재정의할 수 있게 설계되었다. 따라서 인수로 받은 객체가 '진짜'인지 확인하고, 만약 신뢰할 수 없는 하위 클래스의 인스턴스라면 이 인수들은 가변으로 가정하고 방어적으로 복사해서 사용해야한다.

7.  불변 객체 기준

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

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

String 클래스는 불변 객체이지만, non-final 필드인 hash를 통해 hashCode 연산 비용을 절약한다.

8. 정리

• 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
• 성능 때문에 어쩔 수 없다면 가변 동반 클래스를 public 클래스로 제공하자.
• 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
• 꼭 변경해야할 필드를 제외하고, 모든 필드는 private final로 선언해야 한다.
• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
  (확실한 이유가 없다면 생성자/정적팩터리 외에는 어떤 초기화 메서드도 public으로 제공하면 안된다)