이펙티브 자바 Item 17 - 변경 가능성을 최소화하라

 

불변 클래스는 별다른 동기화 방법을 적용하지 않았다 해도 어느 쓰레드에서건 마음껏 안전하게 사용할 수 있다.

 

불변 클래스란 그 인스턴스의 내부 값을 수정할 수 없는 클래스를 의미한다.

 

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

 

String, 기본 타입의 박싱된 클래스, BigInteger, BigDecimal 등이 여기에 속한다.

 

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

 

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

---

2. 불변 객체의 장점

 

2.1 불변 객체는 단순하다 

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

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

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

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

• 스레드 간 영향을 주고받을 수 없기 때문에 안심하고 공유할 수 있다.
• 방어적 복사도 필요없다 
  • 아무리 복사해봐야 원본과 똑같으니 복사 자체가 의미가 없다.
  • 불변 클래스는 clone 메서드나 복사 생성자를 제공하지 않는 게 좋다.
  • String 클래스의 복사 생성자는 되도록 사용하지 말자 (Item 50,13,6)

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

• 자주 사용되는 인스턴스는 캐싱하여 같은 인스턴스를 중복 생성하지 않는다. (GC비용 줄이기)
• 캐싱 방법 : 자주 쓰이는 값들을 상수로 제공, 정적 팩토리로 제공 

2.5 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터 공유 가능 

• BigInteger 클래스를 살펴보면, 부호와 크기를 각각의 필드로 표현
• 가변인 배열을 복사하지 않고 원본 인스턴스와 공유하여 사용

public class BigInteger extends Number implements Comparable<BigInteger> {
    final int signum;//부호
    final int[] mag;//크기(절댓값)

    // ...코드 생략

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

 

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

• 불변 객체는 맵의 키와 Set의 원소로 쓰기 좋다. 
• Map, Set의 구성요소들을 불변 객체로 사용 -> Map이나 Set은 안에 담긴 값이 바뀌면 불변식이 망가지는데 불변 객체를 사용하면 그런 걱정은 하지 않아도 된다.

2.7 불변 객체는 그 자체로 실패 원자성을 제공한다. (상태가 절대 변하지 않으니 잠깐이라도 불일치 상태에 빠질 가능성이 없다)

• 실패 원자성: 메서드에서 예외가 발생한 후에도 그 객체는 메서드 호출전 상태와 같은 유효한 상태를 가진다.

---

3. 불변 객체의 단점

• 값이 다르면 반드시 독립된 객체로 만들어야한다. 
• 값의 가짓수가 많으면 이를 모두 만드는데 큰 비용이 필요하다. 
  • BingInteger를 예시로 들면, flibBit 메서드가 있는데 새로운 BigInteger 인스턴스를 생성할 떄 원본과 단지 한 비트만 다름에도 백만 비트짜리 인스턴스를 또 생성하는 것이다.
  • 이 연산은 BigInteger의 크기에 비례해 시간과 공간을 잡아 먹는다. 
  • BigInteger와 같이 원하는 객체를 완성하기까지의 단계가 많고 중단 단계에서 만들어진 객체는 모두 버려야 한다면 성능 문제가 불거진다. 
  • 따라서 이럴 땐 다음과 같이 처리한다.
    • 다단계 연산 예측이 될 때, 연산 속도를 높여주는 가변 동반 클래스 compainon class를 package-private로 두기 
    • 예측이 안될 때, 가변 동반 클래스를 public으로 제공하기 (String과 StringBuilder)

---

 

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

 

1. final 클래스 : 상속을 막는다.

 

2. 정적 팩토리를 제공한다. 

• final 클래스보다 더 유연한 설계로 상속을 막을 수 있다.
• 모든 생성자를 private 혹은 package-private로 만들고 public 정적 팩토리를 제공한다.
• 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다 
• public이나 protected 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는게 불가능

---

5. BigInteger, BigDecimal 설계 시 주의점

• 두 클래스의 메서드가 모두 재정의할 수 있게 설계되어있음 
• 인수로 받은 객체가 진짜인지 확인하고, 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면, 인수들은 가변으로 가정하고 방어적으로 복사해서 사용해야한다.
• BigInteger를 상속받은 새로운 클래스를 만들 경우, 해당 자식 클래스는 가변 클래스일 수 있다. 
• 클라이언트/개발자는 이 자식 클래스가 부모 타입인 BigInteger로 오해하여 thread safe하다고 생각할 수 있다. 따라서 타입을 확인해야 한다.

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

 

---

6. 불변 객체 기준 완화 

• 어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다.
• 계산 비용이 큰 값을 나중에 계산하여 final이 아닌 필드에 캐싱해둔다.
• String 또한 hashCode 메서드가 처음 불렀을 때 해시 값을 계산해 final 필드가 아닌 hash필드에 캐시한다.
• 이 때 지연초기화 방식을 사용한다 -> hashCode 재연산 비용을 줄일 수 있다. 

public final class MyClass {
	//..생략
    private final byte[] value;
    private int hash;
    //..생략 
    
    
    public int hashCode(){
    	int h = this.hash;
        if(h==0 && this.value.length > 0){
        	//객체에 값이 있고, 해쉬가 0이라면 해쉬코드 생성
        }
    }
}

---

7. 정리

• 클래스가 꼭 필요한 경우가 아니면 불변이어야 한다. (getter가 있다고 해서 setter를 무조건 만들지는 말자)
• 무거운 값 객체의 경우 성능 때문에 어쩔수 없다만, 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하자 
• 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자
• 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야한다.

---

참고자료 

 

https://velog.io/@meme2367/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C-%EC%9E%90%EB%B0%94-%EC%95%84%EC%9D%B4%ED%85%9C-17-%EB%B3%80%EA%B2%BD-%EA%B0%80%EB%8A%A5%EC%84%B1%EC%9D%84-%EC%B5%9C%EC%86%8C%ED%99%94%ED%95%98%EB%9D%BC

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

https://javabom.tistory.com/19

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