item 17 Jung inchul - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

Effective Java 3e 아이템 17를 요약한 내용 입니다.

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

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

• 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다.
• 클래스를 확장할 수 없도록 한다. 상속을 막는 대표적인 방법은 클래스를 final로 선언하는 것이지만, 다른 방법도 뒤에 살펴볼 것이다.
• 모든 필드를 final로 선언한다.
• 모든 필드를 private으로 선언한다.
• 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 이런 필드는 절대 클라이언트가 제공한 객체 참조를 가리키게 해서는 안 되며, 접근자 메서드가 그 필드를 그대로 반환해서도 안 된다. 생성자, 접근자, readObject 메서드 모두에서 방어적 복사를 수행하라

    public final class Complex {
    	private final double re;
    	private final double im;
    
    	public Complex(double re, double im) {
    		this.re = re;
    		this.im = im;
    	}
    
    	...
    
    	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);
    	}
    
    	@Override public boolean equals(Object o) {
    		if (o == this)
    			return true;
    		if (!(o instanceof Complex))
    			return false;
    		Complex c = (Complex) o;
    
    		return Double.compare(c.re, re) == 0
    						&& Double.compare(c.im, im);
    	}

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

불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없기 때문에 안심하고 공유할 수 있다. 따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하기를 권한다.

불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있다. 새로운 클래스를 설계할 때 public 생성자 대신 정적 팩터리를 만들어두면, 클라이언트를 수정하지 않고도 필요에 따라 캐시 기능을 나중에 덧붙일 수 있다.

BigInteger answer = BigInteger.valueOf(42L);

불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다. 객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다. 좋은 예로, 불변 객체는 맵의 키와 집합(Set)의 원소로 쓰기에 안성맞춤이다. 맵이나 집합은 안에 담긴 값이 바뀌면 불변식이 허물어지는데, 불변 객체를 사용하면 그런 걱정은 하지 않아도 된다.

불변 클래스에도 단점은 있다.

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

    BigInteger moby = ...;
    moby = moby.flipBit(0);

이 문제에 대처하는 방법은 두 가지다.

첫 번째는 흔히 쓰일 다단계 연산 들을 예측하여 기본 기능으로 제공하는 방법이다. 이러한 다단계 연산을 기본으로 제공한다면 더 이상 각 단계마다 객체를 생성하지 않아도 된다. 클라이언트들이 원하는 복잡한 연산 들을 정확히 예측할 수 있다면 package-private의 가변 동반 클래스만으로 충분하다. 자바 플랫폼 라이브러리에서 이에 해당하는 대표적인 예가 바로 String 클래스다. 그렇다면 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(double re, double im) {
    		return new Complex(re,im);
    	}
    	...
    }

패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다. public 이나 protected 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는 게 불가능하기 때문이다.

게터(getter)가 있다고 해서 무조건 세터(setter)를 만들지는 말자. 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.

PhoneNumber와 Complex 같은 단순한 값 객체는 항상 불변으로 만들자. 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소환으로 줄이자. 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬어지고 오류가 생길 가능성이 줄어든다.

java.util.concurrent 패키지의 CountDownLatch 클래스가 이상의 원칙을 잘 반증한다. 비록 가변 클래스지만 가질 수 있는 상태의 수가 많지 않다.

CountDownLatch 구조는 어떻게 되어 있나?