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

• 불변 클래스란 그 인스턴스의 내부 값을 수정할 수 없는 클래스임(자바에 String, 기본 타입의 박싱된 클래스들, BingInteger, BigDecimal이 이에 속함)

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

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

클래스를 불변으로 만드는 규칙

• 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않음

• 클래스를 확장할 수 없도록 함

  • 하위 클래스에서 객체의 상태를 변하게 만드는 것을 막아줌

  • 대표적으로 final을 쓰지만, 다른 방법도 있음

• 모든 필드를 final로 선언함

  • 시스템이 강제하는 수단을 이용해 설계자의 의도를 드러냄

  • 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하는데 필요

• 모든 필드를 private로 선언함

  • 칠드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아줌

  • public final 로 해도 불변 객체가 되지만, 다음 릴리스때 내부 표현을 바꾸지 못하므로 권하지 않음

• 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 함

  • 클래스에 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야함

  • 이런 필드는 절대 클라이언트가 제공한 객체 참조를 가리키게 해서는 안되며, 접근자 메서드가 그 필드를 그대로 반환해서는 안됨, 생성자, 접근자, readObject 메서드 모두에서 방어적 복사를 수행하라

readObject 메서드?

readObject 메서드

이번 아이템은 변경 가능성을 최소화하기 위해 불변 객체로써 만들어서 그 가능성을 최소화 하는 것인데 여기서 readObject메서드 같은 경우는 자주 본 사항이 아니어서 찾아봤음

이 readObject도 방어적 복사를 수행하라는 것은 readObject 메서드는 직렬화 과정에서 역직렬화 과정시 사용되는 메소드인데 이 직렬화 역시도 방어적 복사를 하지 않으면 위에서 언급한대로 불변객체로써의 이점도 얻지 못하고 효용이 없기 때문에 이를 언급한 것임

직렬화 과정에서 this를 통해 반환하지만 이는 불변 객체로써 변경 가능성의 가능성을 오히려 늘리는 방법이므로 방어적 복사를 수행하여 진행하라는 것

예시

• 불변 복소수 클래스

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 double realPart() { return re; }
		public double imaginaryPart() { return 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);
		}

		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);
		}

		@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) == 0;
		}

		@Override public int hashCode() {
				return 31 * Double.hashCode(re) + Double.hashCode(im);
		}
		
		@Override public String toString() {
				return "(" + re + " + " + im + "i)";
		}
}

• 복소수에 대한 표현과 몇 가지 메서드 재정의와 접근자 메서드와 사칙연산 메서드를 정의함

• 위처럼 피연산자에 함수를 적용해 그 결과를 반환하지만 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라고 함

• 이와 달리 절차적 혹은 명령형 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변함

• 메서드 이름으로 동사(add 같은) 대신 전치사(plus 같은)를 사용한 점도 확인해야함, 이는 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도임

• 함수형 프로그래밍으로 처리를 한다면 불변이 되는 영역의 비율이 높아짐

함수형 프로그래밍?

함수형 프로그래밍

함수형 프로그래밍은 객체지향 프로그래밍과 같은 하나의 패러다임 중 하나임

객체지향 프로그래밍에서는 객체를 만들어서 참조를 하고 구분을해서 쓰지만 함수형의 경우 그 형태 자체를 함수로 선언하고 람다식이나 고차함수를 통해서 반환값을 함수로 쓰거나 함수를 응용하는 방식을 통해서 처리를 할 수 있는 것임

마치 변수를 쓰듯이 활용이 가능함 자주 접하는 방식은 람다식을 통한 활용임

어쨌든 이런식의 방식이 객체를 참조해 this와 같이 피연산자를 수정해야하는 경우가 생기는 것과는 다르게 그 자체를 반환함으로써 해당 아이템에서 말하는 변경 가능성을 최소화 시키기 위한 불변 객체로써의 만드는 것이 한층 더 수월해지기 때문에 그럼

함수형 프로그래밍

불변 객체

• 불변 객체는 단순함, 생성된 시점의 상태를 파괴될 때까지 그대로 간직함

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

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

• 불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요 없음, 불변 객체에 대해서는 그 어떤 스레드도 다른 스레드에 영향을 줄 수 없으니 불변 객체는 안심하고 공유할 수 있음

• 따라서 불변 클래스라면 한 번 만든 인스턴스를 최대한 재활용하기를 권함

  • 가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것

    // Complex 클래스 상수 제공
    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 메서드나 복사 생성자를 제공하지 않는게 좋음(String 복사 생성자는 그래서 되도록 쓰지 말자)

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

  • BigInteger 클래스의 경우 원본 인스턴스가 가리키는 내부 배열을 그대로 가리킴

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

  • 그 구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월함

• 불변 객체는 그 자체로 실패 원자성을 제공함

  • 즉, 메서드에서 예외가 발생한 후에도 그 객체는 여전히(메서드 호출 전과 똑같은) 유효한 상태여야 한다는 성질

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

단점

• 값이 다르면 반드시 독립된 객체로 만들어야 함

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

• 예를 들어 백만 비트짜리 BigInteger에서 비트 하나를 바꿔야 한다고 할 때 새로운 BigInteger 인스턴스를 생성하는데 이는 원본과 단지 한 비트만 다른 백만 비트짜리 인스턴스를 만드는 것임

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

• 이를 해결하는 데 있어서 먼저 다단계 연산들을 예측하여 기본 기능으로 제공하는 법이 있음

  • 이 다단계 연산을 기본으로 제공한다면 더 이상 각 단계마다 객체를 생성하지 않아도 됨

  • 예를 들어 BigInteger 에서는 다단계 연산 속도를 높여주는 가변 동반 클래스를 package-private으로 두고 있음, 그래서 이걸 사용하는것은 어려운데 이를 BigInteger 가 처리해줌

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

가변 동반 클래스?

가변 동반 클래스

가변 동반 클래스는 불변 클래스와 거의 동일한 기능을 가지고 있지만 가변적인 클래스를 말함 즉, 불변 클래스가 비즈니스 로직 연산 등 시간 복잡도가 높은 연산시 불필요한 생성을 막기 위해 내부적으로 사용함

String클래스의 경우도 이에 해당하는데 문자열 생성을 통해서 문자열을 계속 생성하고 합치는 상황에서 매번 이를 독립된 객체로 만드는 것과 중간에 쓰지 않는데 사용하는 등의 상황이 일어날 수 있음

그 때 StringBuilder의 경우 String을 생성하더라도 가변 동반 클래스로써 String에서의 연산을 도와줄 수 있음

이 외에도 BigInteger의 경우도 모듈러 연산 등 내부 연산을 빠르게 하기 위한 클래스로써 존재하는 경우가 있음

불변 클래스에 또 다른 설계법

• 앞서 알아본 규칙 중에 자신을 상속하지 못하게 하는 가장 쉬운 방법이 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이나 proteceted 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는 게 불가능하기 때문임

• 정적 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 이에 더해 다음 릴리스에서 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있음

• 하지만 BigInteger BigDecimal 의 경우 그렇게 설계하지 못하였고 만약 이 인스턴스를 인수로 받을 때 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면, 이 인수들은 가변이라 가정하고 방어적으로 복사해 사용해야함

• 규칙 목록에서 모든 필드가 final이고 어떤 메서드도 그 객체를 수정할 수 없어야 한다고 했는데 이 규칙은 성능을 위해 아래 정도로 완화할 수 있음

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

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

정리

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

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

• 단순한 값 객체는 항상 불변으로 만들자

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

• 모든 클래스를 불변으로 만들 수는 없음, 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자

• 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어듬, 그러니 꼭 변경해야 할 필드를 뺀 나머지 모두를 final로 선언함

• 다른 합당한 이유가 없다면 모든 필드는 private final 이어야 함

• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야함

• 확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안됨

• 객체를 재활용할 목적으로 상태를 다시 초기화하는 메서드도 안됨