불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다.
불변 인스턴스에 간직된 정보는 고정되어 객체가 파괴되는 순간까지 절대 달라지지 않는다.
자바 플랫폼 라이브러리에도 다양한 불변 클래스가 있다.
String, 기본 타입의 박싱된 클래스들, BigInteger와 BigDecimal 등이 여기 속한다.
클래스를 불변으로 만들려면 다음 다섯 가지 규칙을 따르면 된다.
- 객체의 상태를 변경하는 메서드를 제공하지 않는다.
- 클래스를 확장할 수 없도록 한다. 하위 클래스에서 부주의하게 혹은 나쁜 의도로 객체의 상태를 변하게 하는 것을 막는다.
- 모든 필드를 final로 선언한다. 시스템이 강제하는 수단을 이용해 설계자의 의도를 명확히 드러내는 방법이다. 새로 생성된 인스턴스를 동기화 없이 다른 스레드로 건네도 문제없이 동작하게끔 보장하는 데도 사용한다.
- 모든 필드를 private로 선언한다. 필드가 참조하는 가변 객체를 클라이언트에서 직접 접근해 수정하는 일을 막아준다.
- 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 클래스에 가변 객체를 참조하는 필드가 하나라도 있다면 클라이언트에서 그 객체의 참조를 얻을 수 없도록 해야한다.이런 필드는 절대 클라이언트가 제공한 객체 참조를 가리키게 해서는 안되며, 접근자 메서드가 그 필드를 그대로 반환해서도 안 된다.
// 코드 17-1 불변 복소수 클래스 (106-107쪽)
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;
}
public double realPart() { return re; }
public double imaginaryPart() { return im; }
public Complex plus(Complex c) {
return new Complex(re + c.re, im + c.im);
}
// 코드 17-2 정적 팩터리(private 생성자와 함께 사용해야 한다.) (110-111쪽)
public static Complex valueOf(double re, double im) {
return new Complex(re, 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;
// == 대신 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)";
}
}
이 클래스는 복소수를 표현한다.
Object의 메서드 equals, hashCode, toString을 재정의했고, 접근자 메서드와 사칙연산 메서드를 정의했다.
이 사칙연산 메서드들이 인스턴스 자신은 수정하지 않고 새로운 Complex 인스턴스를 만들어 반환하는 모습에 주목하자.
이처럼 피연산자에 함수를 적용해 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라 한다.
절차적, 명령형 프로그래밍에서는 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.
또한 메서드 이름이 동사 대신 전치사를 사용한 것도 해당 메서드가 객체의 값을 변경하지 않는다는 사실을 강조하려는 의도다.
이 방식으로 프로그래밍하면 코드에서 불변이 되는 영역의 비율이 높아지는 장점을 누릴 수 있다.
불변 객체는 단순하다. 불변 객체는 생성된 시점의 상태를 파괴될 때까지 그대로 간직한다.
모든 생성자가 클래스 불변식을 보장한다면 그 클래스를 사용하는 프로그래머가 다른 노력을 들이지 않더라도 영원히 불변으로 남는다.
불변 객체는 근본적으로 ThreadSafe하며 따로 동기화할 필요 가 없다. 때문에 안심하고 공유할 수 있다.
불변 클래스라면 한번 만든 인스턴스를 최대한 재사용하기를 권한다.
가장 쉬운 방법은 자주 쓰이는 값들을 public static final을 이용해 상수로 제공하는 것이다.
자주 쓰이지는 않아도 하드코딩으로 들어갈 값들을 상수로 사용하면 가독성, 유지 보수성, 코드의 일관성 등을 고려할 때 더욱 유리하다.
또한, 불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있다.
한번은 SecureRandom을 이용해 OAuth2에 사용할 토큰을 만들어야 했던 적이 있었다.
public final class SecureRandomUtils {
private static final SecureRandom RANDOM;
static {
try {
RANDOM = SecureRandom.getInstance("SHA1PRNG");
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException("Failed to initialize SecureRandomUtils", e);
}
}
....
}
SecureRandom은 특정 알고리즘을 사용해서 인스턴스를 만들어줘야 한다.
하나의 알고리즘만 사용하는 상황이였고, 여러 곳에서 사용 될 부분이였기 때문에 인스턴스를 중복해서 생성하지 않게 static finial을 이용해서 만들어주었다.
이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.
불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있다.
객체를 만들 떄 다른 불변 객체들을 구성요소로 사용하면 이점이 많다.
불변식을 유지하기 훨씬 수월하기 때문에 구조가 객체의 복잡하더라도 걱정을 덜 수 있다.
불변 객체는 그 자체로 실패 원자성을 제공한다.
불변 클래스의 단점은 값이 다르면 반드시 독립된 객체로 만들어야하기 때문에 가짓수가 많다면 이들을 모두 만드는 데 큰 비용을
치러야 할 수 있다.
String은 앞서 말했듯이 불변 객체이다.
String a = "1";
a = "2";
이러한 방식으로 String 객체의 값을 변경해도 아무 문제가 없다.
하지만 같은 인스턴스의 값이 변경되는 것이 아닌 기존 인스턴스가 삭제되고 새로운 인스턴스가 생성된다.
만약 길이 100만의 String 값이 있고, 중간에 한 단어를 바꿔야 한다고 할 때,
원본과 단 한단어만 차이가 나는 length 100만의 새로운 인스턴스가 생성되는 것이다.
이를 위해 StringBuilder 같은 클래스가 존재한다.
StringBuilder는 변경이 가능한 문자열을 만들어주기 때문에, 문자열을 연산하는 과정에서 하나의 대안이 될 수 있겠다.
이런 클래스를 가변 동반 클래스라고 한다.
이러한 방식 외에 불변 클래스를 만드는 다른 방식이 몇가지 있다.
하나는 정적 팩터리를 이용하는 것이다.
이 방식이 최선일 때가 많은데, 바깥에서 볼 수 없는 package-private 구현 클래스를 원하는 만큼 만들어 활용할 수 있으니 훨씬 유연하다.
객체 캐싱 기능을 추가해 성능을 올릴 수도 있다.
불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이는 것이 좋다.
객체가 가질 수 있는 상태의 수를 주리면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다.
다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.
생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
'JAVA > 이펙티브 자바' 카테고리의 다른 글
19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 (0) | 2023.07.03 |
---|---|
18. 상속보다는 컴포지션을 사용하라 (0) | 2023.07.01 |
16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 (0) | 2023.07.01 |
15. 클래스와 멤버의 접근 권한을 최소화하라 (0) | 2023.07.01 |
14. Comparable을 구현할지 고려하라 (0) | 2023.07.01 |