[Effective Java] 아이템 17. 변경 가능성을 최소화하라

EFFECTIVE JAVA(이펙티브 자바)

 

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다.

---

아이템 17. 변경 가능성을 최소화하라

 

불변 클래스

• 인스턴스의 내부 값을 수정할 수 없는 클래스.
• 즉, 불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 변하지 않는다.
  ex) String, 기본 타입의 박싱 클래스, BigInteger, BigDecimal 등
• 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전함

 

불변 클래스 생성 규칙

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

 

 

불변 클래스의 장점

• 단순하다.
  불변 객체는 생성된 시점의 상태를, 파괴될 때까지 그대로 간직한다.
• 근본적으로 스레드 안전하여 따로 동기화할 필요가 없다.
  여러 스레드가 동시에 사용해도 절대로 훼손되지 않는다.
• 안심하고 공유할 수 있다.
  불변 클래스라면 한 번 만든 인스턴스르 최대한 재활용하면 좋다.
  ex) 자주 쓰이는 값들을 상수(public static final)로 제공
• 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리 내부 데이터를 공유할 수 있다.
  예로  BigInteger 클래스는 내부에서 값의 부호(sign)와 크기(magnitude)를 따로 표현한다. 부호에는 int 변수를, 크기(절댓값)에는 int 배열을 사용하는 것이다. 한편 negate 메서드는 크기가 같고 부호만 반대인 새로운 BigInteger를 생성하는데, 이때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다. 그 결과 새로 만든 BigInteger 인스턴스도 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.
• 객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다.
• 그 자체로 실패 원자성을 제공한다.
  상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없다.

 

 

불변 클래스의 단점

값이 다르면 반드시 독립된 객체로 만들어야 한다.
ex) 백만 비트짜리 BigInteger에서 비트 하나를 바꿔야 한다면, 새로운 인스턴스를 생성해야함
원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려질 경우 성능 문제가 발생한다.

 

- 해결 방법

• 다단계 연산 예측이 될 때. 연산 속도를 높여주는 가변 동반 클래스 companion class를 package-private으로 사용
• 예측이 안될때. 가변 동반 클래스를 public으로 제공
  ex) String과 가변 동반 클래스 StringBuilder

 

 

 

클래스가 자신을 상속하지 못하게 하는 방법

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

 

 

 

BigInteger와 BigDecimal 사용 시, 주의점

• 이 두 클래스의 메서드들은 모두 재정의할 수 있게 설계되었고, 안타깝게도 하위 호환성이 발목을 잡아 지금까지도 이 문제를 고치지 못했다. 
• 그러니 만약 신뢰할 수 없는 클라이언트로부터 BigInteger나 BigDecimal의 인스턴스를 인수로 받는다면 주의해야 한다.
• 이 값들이 불변이어야 클래스의 보안을 지킬 수 있다면 인수로 받은 객체가 '진짜' BigInteger(혹은 BigDecimal)인지 반드시 확인해야 한다.
• 다시 말해 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면, 이 인수들은 가변이라 가정하고 방어적으로 복사해 사용해야 한다.

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

 

 

 

불변 객체의 기준을 완화하는 방법

위에서 소개한 불변객체 규칙은 좀 과한 감이 있어 성능을 위해 아래처럼 완화할 수 있다.

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

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

 

 

 

정리

• 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
  getter가 있다고 해서 무조건 setter를 만들지는 말자.
  불변 클래스는 장점이 많으며, 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐이다.
• String과 BigInteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 고심해야 한다.
  성능 때문에 어쩔 수 없다면 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 하자. 
  한편, 모든 클래스를 불변으로 만들 수는 없다.
• 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
  객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다.
  그러니 꼭 변경해야 할 필드를 뺀 나머지 모두를 final로 선언하자.
• 이번 아이템과 아이템 15의 조언을 종합한다면 다음과 같다.
  다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
  확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안 된다. 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안 된다. 복잡성만 커지고 성능 이점은 거의 없다.