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

4장. 클래스와 인터페이스 - GOAL

추상화의 기본 단위인 클래스와 인터페이스는 자바의 심장이다.
클래스와 인터페이스를 쓰기 편하고, 견고하며, 유연하게 만들어보자

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

불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스다.
불변 인스턴스에 간직된 정보는 고정되어, 객체가 파괴되는 순간까지 절대 달라지지 않는다.
String, 기본타입의 박싱된 클래스들, BigInteger, BigDecimal 이 예시로 있다.

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

클래스를 불변으로 만들기 위한 규칙 5개

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

불변 클래스 예제

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

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

    //.. 코드 생략

    public Complex plus(Complex c){
        return new Complex(re + c.re, im + c.im);
    }
}

불변 객체의 장점

1. 불변 객체는 단순하다.

불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다.
모든 생성자가 클래스 불변식을 보장한다면, 그 클래스를 사용하는 프로그래머가 다른 노력을 들이지 않더라도 영원히 불변으로 남는다.

반면, 가변 객체는 임의의 복잡한 상태에 놓일 수 있다.
변경자 메서드가 일으키는 상태 전이를 정밀하게 문서로 남겨놓지 않은 가변 클래스는 믿고 사용하기 어려울 수도 있다.

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

여러 스레드가 동시에 사용해도 절대 훼손되지 않는다.

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

불변 객체에 대해서는 그 어떤 스레드도 다른 스레드에 영향을 줄 수 없으니, 안심하고 공유할 수 있다.
따라서, 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권한다.
가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것이다.

불변 객체를 자유롭게 공유할 수 있다는 점은 방어적 복사도 필요없다는 결론으로 이어진다.
아무리 복사해봐야 원본과 똑같으니 복사 자체가 의미가 없다.
그러니 불변 클래스는 clone 메서드나 복사 생성자를 제공하지 않는게 좋다.

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

BigInteger 클래스는 내부에서 값의 부호(sign)와 크기(magnitude)를 따로 표현한다.
부호에는 int 변수, 크기에는 int 배열을 사용한다.
negate 메서드는 크기가 같고, 부호만 반대인 새로운 BigInteger를 생성하는데, 이때 배열은 비록 가변이지만 복사하지않고, 원본 인스턴스와 공유해도 된다.

public BigInteger negate() {
    return new BigInteger(this.mag, -this.signum);
    // 새로우 인스턴스는 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킨다.
}

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

값이 바뀌지 않는 구성요소들로 이뤄진 객체라면, 그 구조가 복잡하더라도 불변식을 유지하기 훨씬 수월하기 때문이다.
불변 객체는 map의 key로 쓰거나 Set의 원소로 쓰면 딱이다.
맵이나 집합은 안에 담긴 값이 바뀌면 불변식이 허물어지는데, 불변 객체를 사용하면 그런 걱정은 하지 않아도 된다.

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

상태가 절대 변하지 않으니, 잠깐이라도 불일치 상태에 빠질 가능성이 없다.
참조) 실패 원자성 : 메서드에서 예외가 발생한 후에도 그 객체는 여전히 메서드 호출 전과 똑같은 유효한 상태여야 한다.

불변 클래스의 단점

값이 다르면 반드시 독립된 객체로 만들어야 한다.
원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제가 더 불거진다.

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

클래스가 불변임을 보장하려면, 자신을 상속하지 못하게 해야한다. 가장 쉬운 방법은 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(double re, double im){
        return new Complex(re,im);
    }
    //나머지 생략
}

결론

getter가 있다고 해서 무조건 setter를 만들지는 말자.

클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
단순한 값 객체는 항상 불변으로 만들자.

모든 클래스를 불변으로 만들 수는 없다.

불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
객체가 가질 수 있는 상태의 수를 줄이면, 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다.
꼭 변경해야할 필드를 뺀 나머지를 모두 final로 선언하자.

합당한 이유가 없다면, 모든 필드는 private final 이어야 한다.

생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안된다.