[아이템 17] 변경 가능성을 최소화하라
불변 클래스란
인스턴스의 내부 값을 수정할 수 없는 클래스
불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다
(String, Boxing클래스, BigInteger, BidDecimal 등)
불변 클래스로 설계하는 이유?
가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다
불변 클래스를 위한 다섯 가지 규칙
- 객체의 상태를 변경하는 메소드(변경자)를 제공하지 않는다.
- 클래스를 확장할 수 없도록 한다. 👉🏻 아이템 19
- 모든 필드를 final로 선언한다.
- 모든 필드를 private으로 선언한다.
- 자신 외에는 내부의 가변 컴포넌트를 접근할 수 없도록 한다.
규칙 세부 내용
클래스를 확장할 수 없도록 한다 : 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 하는 사태를 방지
모든 필드를 final로 선언한다 : 시스템이 강제하는 수단을 이용해 설계자의 의도를 명확하게 드러내는 방법
모든 필드를 private으로 선언 : 클라이언트가 직접 접근해 수정하는 일을 방지. (기술적으로는 public final로만 선언해도 불변 객체가 되지만, 이러면 다음 릴리즈에서 내부 표현을 바꾸지 못해 권장하진 않는다.)
자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다 : 클래스 내부에 가변 객체를 참조하는 필드가 하나라도 있으면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 한다.
다음 예를 통해 더 자세한 상황을 관찰해보자
public final class Complex{
private final double re;
private final double im;
pulic 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) + Doule.hashCode(im);
}
@Override
public String toString(){
return "(" + re + " + " + im + "i)";
}
}
유심히 봐야할 포인트
- 사칙연산 메소드들은 인스턴스 자신을 수정하지 않고(필드 값을 건드리지 않고) 새로운 Complex 인스턴스를 만들어 반환한다.
- 이처럼 피연산자에 함수를 적용해 결과를 반환하되, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다. 절차적 혹은 명령형 프로그래밍에서는 메소드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.
- 또한 add 같은 동사 대신 plus 같은 전치사를 사용한 점도 주목하자. 해당 메소드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도이다.
- 함수형 프로그래밍을 사용하면 코드에서 불변이 되는 영역의 비율이 높아지는 장점을 누릴 수 있다.
불변 객체는 단순하다.
불변 객체는 근본적으로 스레드 안전하여 따로 동기화할 필요가 없다. 따라서 여러 스레드가 동시에 사용해도 절대 훼손되지 않는다. 불변 객체는 안심하고 공유할 수 있다.
따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하자.
그렇기에
가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수(public static final)로 제공하는 것이다.
불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩토리를 제공할 수 있다.
정적 팩토리를 사용하면 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션의 비용이 줄어든다.
새로운 클래스를 설계할 때, public 생성자 대신에 정적 팩토리를 사용하면 차후에 필요에 따라 캐시 기능을 덧붙일 수 있다.
불변 객체를 자유롭게 공유할 수 있다? 따라서 방어적 복사도 필요 없다.
아무리 복사해봐야 원본과 달라질 것이 없으므로 복사 자체가 의미가 없다. 불변 클래스는 clone 메소드나 복사 생성자를 제공하지 않는게 좋다.
방어적 복사란
생성자를 통해 초기화할 때, 새로운 객체로 감싸서 복사해주는 방법이다.
외부와 내부에서 주소값을 공유하는 인스턴스의 관계를 끊어주기 위함이다.
(클라이언트가 불변식을 깨뜨리려 혈안이 되어 있다고 가정하고 프로그래밍하는 방식)
새로운 객체로 감싸서 복사해주는 방법이라면....왜 이렇게?
clone을 사용해서 복사본을 만들 수도 있지만, 생성자의 매개변수가 final 클래스가 아니어서 확장될 수 있는 타입이라면 재정의된 clone이 호출될 수 있기에 사용하면 안된다.
즉, 매개변수가 제3자에 의해 확장될 수 있는 타입이라면 방어적 복사본을 만들 때 clone을 사용해서는 안된다.
생성자에서만 복사본을 만든다고 내부 값을 변경할 수 없는 것이 아니다.
getter로 얻은 객체를 통해 얼마든지 내부 값이 변경될 수 있기 때문이다.
따라서 getter에서도 복사본을 리턴해줘야 한다.
생성자의 매개변수로 원시타입이 넘어온다면 애초에 값이 복사되어 전달되므로 유효성 검사 후 그냥 할당해주어도 괜찮지만, 생성자의 매개변수로 객체가 넘어온다면 먼저 복사본을 만든 후 유효성 검사를 해주는 것이 좋다.
즉, 불변성이 유지된다면 검증부터 해줘도 되지만 그걸 보장할 수 없다면 복사본을 만든 후, 복사본으로 검증해주는 것이 좋다.
유효성 검사 및 방어적 복사에 대한 더 디테일한 내용은 아이템 49와 아이템 50을 참조하자.
불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.
ex) BigInteger 구조 - 부호는 int형 정수, 크기를 int[] 사용하기에, 부호가 반대인 경우인 수를 도출해내는 과정에서 같은 int[] 배열을 공유할 수 있다.
객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다.
구성 요소를 불변 객체로 구성하게 되면 구조가 아무리 복잡하더라도 불변식을 유지하기 훨씬 수월하다
ex) 맵의 키와 집합의 원소
불변 객체는 그 자체로 실패 원자성을 제공한다(아이템 76)
상태가 절대 불변이니 잠깐이라도 불일치 상태에 빠질 가능성이 없다.
불변 클래스의 단점 : 값이 다르면 무조건 독립된 객체로 만들어야 한다.
ex) BigInteger의 비트 중 하나만 바뀌는 경우라도, 값이 다르기에 새로운 객체를 만들어야 한다. 비트 하나에 비해 시간과 공간을 낭비하는 악효과 👉🏻 BitSet 클래스는 '가변'이지만 원히는 비트 하나만을 상수 시간안에 바꿔주는 메소드를 제공한다.
원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제를 야기할 수 있다.
이에 대처하기 위한 방안은 다음과 같다.
흔히 쓰일 다단계 연산(multustep operation)들을 예측하여 기본 기능으로 제공하는 방법
이 방법을 사용하여 각 단계마다 객체를 생성하지 않아도 되어 자원이 낭비되는 것을 방지할 수 있다.
ex) BigInteger는 모듈러 지수같은 다단계 연산 속도를 높여주는 가변 동반 클래스를 package-private으로 두고 있다.
ex) String 클래스에서의 가변 동반 클래스는 StringBuilder & StringBuffer
불변 클래스의 규칙 중 하나 : 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다
자신을 상속하지 못하게 하는 가장 쉬운 방법은 final 클래스로 선언하는 것이지만, 더 유연한 방법으로
모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩토리를 제공하는 방법이다.
public class Complex{
private final double re;
private final double im;
private Complex(doule 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 생성자가 없으니 다른 패키지에서는 사실상 확장이 불가능하다.
정적 팩토리 방식은 다수의 구현 클래스를 활용한 유연성을 제공, 객체 캐싱 기능을 추가할 수 있게 한다.
불변 클래스의 규칙 중 하나 : 모든 필드를 final로 선언하자
좀 과한 설정일수도 있으니..."어떤 메소드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다" 로 생각해보자
어떤 불변 클래스는 계산 비용이 큰 값을 나중에(처음 쓰일 때) 계산하여 final이 아닌 필드에 캐시해 놓기도 한다. 똑같은 값을 다시 요청하면 캐시해둔 값을 반환하여 계산 비용을 절감!
👉🏻 불변 객체이기에 몇 번을 계산해도 같은 값이 반환됨이 보장되기 때문이다.
정리
클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
불변 객체는 장점이 매우 많으며, 단점이라고는 성능 저하뿐이다. 따라서 단순한 값 객체는 항상 불변으로 생성해야 한다.
그렇다고 모든 객체를 불변 객체로 만들 수는 없다. 하지만, 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분은 최소한으로 줄이자. 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다.
합당한 이유가 없으면 모든 필드는 private final이어야 한다.
생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
확실한 이유가 없다면 생성자와 정적 팩토리 외에는 그 어떤 초기화 메소드도 public으로 제공해서는 안된다.