변경 가능성을 최소화하라

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

 

• 불변으로 설계하는 이유는 그럴만한 이유가 있다.
• 불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적어 훨씬 안전한다.

 

 

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

1. 객체의 상태를 변경하는 메서드(변경자)를 제공하지 않는다. 2. 클래스를 확장할 수 없도록 한다. 이는 하위 클래스에서 객체의 상태를 변하게 하는 것을 막는다. 3. 모든 필드를 final로 선언한다. 이는 의도를 명확히 드러낸다. 4. 모든 필드를 private으로 선언한다. 필드가 참조하는 가변 객체를 직접 접근해 수정하는 일을 막는다. 5. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

 

 

 

이 사칙연산 메서드들이 인스턴스 자신은 수정하지 않고, 새로운 Complex 인스턴스를 만들어 반환하는 모습에 주목하자. 

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

 

 

불변클래스의 장점

---

 

 

 

• 불변 객체는 근본적으로 스레드 안전하며 따로 동기화할 필요가 없다.
• 그 어떤 스레드도 다른 스레드에 영향을 주지 않기 때문이다. 따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용하자.
• 가장 쉬운 재활용 방법은 자주 쓰이는 값들을 상수로 제공하는 것이다.

 

 

• 불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있다.
• 박싱된 기본 타입 클래스와 BigInteger가 여기 속한다. 이런 정적 팩터리를 사용하면 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어든다.

 

• 불변 객체는 방어적 복사 역시 필요 없다는 결론으로 이어진다. 아무리 복사해야 원본과 똑같기 때문이다.

 

• 객체를 만들때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다.
• 좋은 예로, 불변 객체는 맵의 키와 Set의 원소로 쓰기에 안성맞춤인데 안에 담긴 값이 바뀌면서 불변식이 허물어지는 일이 없기 때문이다.

 

 

불변클래스의 단점

---

• 값이 다르면 반드시 독립된 객체로 만들어야 하며
• 만일 백만 비트에서 비트 하나를 바꿔야 한다면 이 크기에 비례해 시간과 공간을 잡아먹게 된다.

 

• 이러한 문제들에 대처하는 방법은 두 가지가 있다.
• 첫 번째로 다단계 연산들을 예측하여 기본 기능으로 제공하는 방법이다.
• 예를 들어 BigInteger는 모듈러 지수 같은 다단계 연산 속도를 높여주는 가변 동반 클래스를 두고 있다.
• String 역시 StringBuilder가 가변 동반 클래스에 속한다.

 

 

불변 클래스를 만드는 또 다른 설계 방법

---

• 클래스가 불변임을 보장하려면 자신을 상속하지 못하게 해야 한다고 했다.
• 자신을 상속하지 못하게 하는 가장 쉬운 방법은 final 클래스로 선언하는 것이지만 더 유연한 방법이 있다.
• 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 팩터리를 제공하는 방법이다.

 

• 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final이다.
• publlic이나 protected 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는게 불가능하다.
• 정적 팩터리 방식은 다수의 구현 클래스를 활용한 유연성을 제공하고, 다음 릴리스에서 객체 캐싱 기능을 추가해 성능을 끌어올릴 수도 있다.

 

 

 

정리

---

• Getter가 있다고 해서 무조건 Setter를 만들지는 말자. 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다.
• 불변 클래스는 장점이 많으며, 단점은 특정 상황에서의 잠재적 성능 저하뿐이다.
• 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자.
• 객체가 가지는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다.

 

• 따라서 다른 합당한 이유가 없다면 모든 필드는 private final 이여야 한다.
• 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.
• 확실한 이유가 없다면 생성자와 정적 팩터리 외에는 그 어떤 초기화 메서드도 public으로 제공해서는 안된다.