[effective java] item 17. 변경 가능성을 최소화하라

결론

불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전합니다. 
단점이라곤 특정 상황에서의 잠재적 성능 저하뿐입니다. 
getter가 있다고 해서 무조건 setter를 만들지 말고, 다른 합당한 이유가 없다면 모든 필드는 private final로 선언합시다. 

 

 

설명

참고 불변 클래스?
불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스입니다. 
불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않습니다.
자바 플랫폼 라이브러리에도 다양한 불변 클래스가 있습니다. 
String, 기본 타입의 박싱된 클래스들, BigInteger, BigDecimal이 여기에 속합니다. 

 

 

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

1. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.
2. 클래스를 확장할 수 없도록 한다.
   하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 만드는 사태를 맊아줍니다.
   상속을 막는 대표적인 방법은 클래스를 final로 선언하는 방법과 private 생성자와 정적 팩토리 메서드를 제공하는 방법이 있습니다.
3. 모든 필드를 final로 선언한다.
   시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법입니다. 
4. 모든 필드를 private로 선언한다.
   필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아줍니다. 
   기본 타입 필드나 불변 객체 필드를 public final로 선언해도 불변 객체가 되지만, 내부 표현을 바꾸지 못하므로 권하지는 않습니다.
5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.
   클래스에 가변 객체를 참조하는 필드가 하나라도 있다면, 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야 합니다. 또한, 접근자 메서드가 이 필드를 그대로 반환해서도 안 됩니다. 생성자, 접근자, readObject 메서드 모두에서 방어적 복사를 수행해야 합니다.

예시

public final class Money {
    private final String[] cards;

    ...

    public String[] getCards() {
        return cards.clone();
    }
}​

가변 참조 객체 cards는 final로 지정하더라도 배열 안의 값들에 대해서는 불변이 아닙니다.
따라서, 해당의 접근자 메서드는 clone()을 이용하여 방어적 복사를 수행해야 합니다. 

(출처 : https://seungmu.tistory.com/542)

 

 

불변 클래스 예제: 복소수 클래스

public final class Complex {
    private final double re;	//실수부
    private final double im;	//허수부 

    public static final Complex ZERO = new Complex(0, 0);
    public static final Complex ONE  = new Complex(1, 0);
    public static final Complex I    = new Complex(0, 1);

    public Complex(double re, double im) {
        this.re = re;
        this.im = im;
    }

	//접근자 메서드 (realPart, imaginaryPart)
    public double realPart()      { return re; }
    public double imaginaryPart() { return im; }

	//사칙연산 메서드 (plus, minus, times, dividedBy)
    public Complex plus(Complex c) {
        return new Complex(re + c.re, im + c.im);
    }

    public Complex minus(Complex c) {
        return new Complex(re - c.re, im - c.im);
    }

    public Complex times(Complex c) {
        return new Complex(re * c.re - im * c.im,
                re * c.im + im * c.re);
    }

    public Complex dividedBy(Complex c) {
        double tmp = c.re * c.re + c.im * c.im;
        return new Complex((re * c.re + im * c.im) / tmp,
                (im * c.re - re * c.im) / tmp);
    }

	//Object 메서드 재정의 
    @Override public boolean equals(Object o) {
        if (o == this)
            return true;
        if (!(o instanceof Complex))
            return false;
        Complex c = (Complex) o;

        // == 대신 compare를 사용하는 이유는 63쪽을 확인하라.
        return Double.compare(c.re, re) == 0
                && Double.compare(c.im, im) == 0;
    }
    
    @Override public int hashCode() {
        return 31 * Double.hashCode(re) + Double.hashCode(im);
    }

    @Override public String toString() {
        return "(" + re + " + " + im + "i)";
    }
}

 

사칙연산 메서드: 새로운 Complex 인스턴스를 만들어 반환한다. (함수형 프로그래밍)

• 주목해야 할 점은 사칙연산 메서드들이 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어 반환하는 모습입니다.
• 이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 합니다.
• 이와 달리, 절차적 혹은 명령형 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 됩니다.

 

• 추가로, 메서드 이름으로 (add 같은) 동사 대신 (plus 같은) 전치사를 사용한 점에도 주목해야 합니다.
• 이는 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도입니다. 

 

참고 BigInteger, BigDecimal
참고로 불변 객체인 둘은 이 명명 규칙을 따르지 않아 클래스를 사람이 잘못 사용해 오류가 발생하는 일이 자주 있습니다. 

 

참고 실무에 부적합한 클래스 
해당 Complex 클래스는 불변을 설명하기 위한 예로 든 것일 뿐, 실무에서 쓸 만한 수준은 못됩니다.
복소수 곱셈과 나눗셈을 표준 공식대로 구현했지만, 반올림을 제대로 처리하지 않고 복소수 NaN과 무한대도 다루지 못합니다. 

 

 

 

불변 클래스의 장점

단순합니다.

생성된 시점의 상태를 파괴할 때까지 그대로 간직합니다.

 

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

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

 

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

• 여러 스레드가 동시에 사용해도 절대 훼손되지 않습니다.
• 따라서 불변 객체는 안심하고 공유할 수 있습니다.
• 따라서, 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권합니다. 
• 가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것입니다. 

 

public static final Complex ZERO = new Complex(0, 0);
public static final Complex ONE = new Complex(1, 0);
public static final Complex I = new complex(0, 1)

• 한 걸음 더 들어가, 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있습니다. 
• 박싱된 기본 타입 클래스 전부와 BigInteger가 여기에 속합니다. 
• 이런 정적 팩터리를 사용하면, 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어듭니다. 
• 새로운 클래스를 설계할 때 public 생성자 대신 정적 팩터리를 만들어두면, 클라이언트를 수정하지 않고도 필요에 따라 캐시 기능을 나중에 덧붙일 수 있습니다. 

 

방어적 복사가 필요 없습니다.

아무리 복사해봐야 원본과 똑같으니 복사 자체에 의미가 없습니다. 따라서 불변 클래스는 clone 메서드나 복사 생성자를 제공하지 않는게 좋습니다.

 

 

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

예를 들어, BigInteger 클래스는 내부에서 값의 부호(sign)과 크기(magnitude)를 따로 표현합니다.

부호에는 int 변수를, 크기(절댓값)에는 int 배열을 사용합니다.

한편, negate 메서드는 크기가 같고 부호만 반대인 새로운 BigIntger를 생성하는데, 이때 배열은 비록 가변이지만 복사하지 않고 원본 인스턴스와 공유해도 됩니다. 

그 결과 새로 만든 BigInteger 인스턴스도 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킵니다.

 

 

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

좋은 예로, 불변 객체는 맵의 키와 집합(Set)의 원소로 쓰기에 안성맞춤입니다.

맵이나 집합은 안에 담긴 값이 바뀌면 불변식이 허물어지는데, 불변 객체를 사용하면 그런 걱정은 하지 않아도 됩니다.

 

 

실패 원자성을 제공합니다.

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

참고 실패 원자성(failure automicity)
'메서드에서 예외가 발생한 후에도 그 객체는 여전히 (메서드 호출 전과 똑같은) 유효한 상태여야 한다'는 성질입니다. 

 

 

지연 초기화에 사용할 수 있습니다.

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

똑같은 값을 다시 요청하면 캐시해둔 값을 반환하여 계산 비용을 절감하는 것이빈다.

이 묘수는 순전히 그 객체가 불변이기 때문에 부릴 수 있는데, 몇 번을 계산해도 항상 같은 결과가 만들어짐이 보장되기 때문입니다. 

 

예를 들어, PhoneNumber의 hashCode 메서드는 처음 불렸을 때 해시 값을 계산해 캐시합니다.

 

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;

    ...

    // 해시코드를 지연 초기화하는 hashCode 메서드 - 스레드 안정성까지 고려해야 한다. (71쪽)
    private int hashCode; // 자동으로 0으로 초기화된다.

    @Override public int hashCode() {
        int result = hashCode;
        if (result == 0) {
            result = Short.hashCode(areaCode);
            result = 31 * result + Short.hashCode(prefix);
            result = 31 * result + Short.hashCode(lineNum);
            hashCode = result;
        }
        return result;
    }
}

 

 

 

불변 클래스의 단점: 값이 다르면 반드시 독립된 객체로 만들어야 한다.

값의 가짓수가 많다면 이들을 모두 만드는 데 큰 비용을 치러야 합니다.

 

예를 들어, 백만 비트짜리 BigInteger에서 비트 하나를 바꿔야 한다고 해봅시다.

 

BigInteger moby = ...;
moby = moby.flipBit(0);		//원본과 단지 한 비트만 다른 백만 비트짜리 새로운 인스턴스를 생성한다.

• BigInteger의 크기에 비례해 시간과 공간을 잡아먹습니다. 
• BigSet도 BigInteger처럼 임의 길이이 비트순열을 표현하지만, BigInteger와는 달리 '가변'이므로, 원하는 비트 하나만 상수 시간 안에 바꿔주는 메서드를 제공합니다. 

 

BigSet moby = ...;
moby.flip(0);			// 상수 시간안에 새 인스턴스를 생성하지 않고 비트를 바꾼다.

 

원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제가 더 불거집니다. 

 

 

해결책: 동반 클래스(companion class)

다단계 연산(multiset operation)들을 예측하여 기본 기능으로 제공하는 방법입니다.

예를 들어, BigInteger는 모듈러 지수 같은 다단게 연산 속도를 높여주는 가변 동반 클래스를 private-package로 두고 있습니다.

이러한 다단계 연산을 사용하면 더 이상 각 단계마다 객체를 생성하지 않아도 됩니다. 

 

클라이언트들이 원하는 복잡한 연산들을 정확히 예측할 수 있다면 package-private의 가변 동반 클래스만으로 충분하지만, 그렇지 않다면 이 클래스를 public으로 제공하는 것이 최선입니다.

 

자바 플랫폼 라이브러리에서는 이에 해당하는 대표적인 예가 String입니다.

String의 가변 동반 클래스로는 StringBuilder가 있습니다.

 

 

 

주의: BigInteger와 BigDecimal는 final이 붙어있지 않다.

BigInteger와 BigDecimal을 설계할 당시엔 불변 객체가 사실상 final이어야 한다는 사실이 널리 퍼지지 않았습니다.

따라서 이 두 클래스는 모두 재정의할 수 있게 설계되었습니다. 

그러니 만약 실뢰할 수 없는 클라이언트로부터 BigInteger나 BigDecimal의 인스턴스를 인수로 받는다면 주의해야 합니다.
이 값들이 불변이어야 클래스의 보안을 지킬 수 있다면, 인수로 받은 객체가 '진짜' BigInteger(혹은 BigDecimal)인지 반드시 확인해야 합니다.

만약, 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면, 이 인수들은 가변이라 가정하고 방어적 복사를 사용해야 합니다.

 

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

 

 

 

 

결론1: 게터(getter)가 있다고 해서 무조건 세터(Setter)를 만들지는 말자.

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

불변 클래스는 장점이 많으며, 단점이라곤 특정 상황에서의 잠재적 성능 저하뿐입니다. 

 

PhoneNumber와 Complex 같은 단순한 값 객체는 항상 불변으로 만듭시다. 

String과 BigInteger처럼 무거운 값 객체도 불변으로 만들 수 있는지 고심해야 합니다. 성능 때문에 어쩔 수 없다면 불변 클래스와 쌍을 이루는 가변 동반 클래스를 public 클래스로 제공하도록 합시다.

 

 

 

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

객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어듭니다.

꼭 변경해야 할 필드를 뺀 나머지 모두를 final로 선언합시다. 

item 15의 조언을 조합하면 다른 합당한 이유가 없다면 모든 필드는 private final 이어야 합니다. 

 

java.util.concurrent 패키지의 CountDownLatch 클래스가 이상의 원칙을 잘 방증합니다.

비록 가변 클래스지만 가질 수 있는 상태의 수가 많지 않고 인스턴스를 생성해 한 번 사용하면 그걸로 끝입니다. 

카운트가 0에 도달하면 더는 재사용할 수 없습니다. 

 

CountDownLatch 클래스

package java.util.concurrent;
import java.util.concurrent.locks.AbstractQueuedSynchronizer;

public class CountDownLatch {

    private static final class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = 4982264981922014374L;

        Sync(int count) {
            setState(count);
        }

        int getCount() {
            return getState();
        }

        protected int tryAcquireShared(int acquires) {
            return (getState() == 0) ? 1 : -1;
        }

        protected boolean tryReleaseShared(int releases) {
            // Decrement count; signal when transition to zero
            for (;;) {
                int c = getState();
                if (c == 0)
                    return false;
                int nextc = c-1;
                if (compareAndSetState(c, nextc))
                    return nextc == 0;
            }
        }
    }

    private final Sync sync;
    
    public CountDownLatch(int count) {
        if (count < 0) throw new IllegalArgumentException("count < 0");
        this.sync = new Sync(count);
    }

    public void await() throws InterruptedException {
        sync.acquireSharedInterruptibly(1);
    }

    public boolean await(long timeout, TimeUnit unit)
        throws InterruptedException {
        return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout));
    }

    public void countDown() {
        sync.releaseShared(1);
    }

    public long getCount() {
        return sync.getCount();
    }

    public String toString() {
        return super.toString() + "[Count = " + sync.getCount() + "]";
    }
}

 

 

---

출처

https://www.yes24.com/Product/Goods/65551284

이펙티브 자바 Effective Java 3/E - 예스24