1. 불변 클래스
불변 클래스란 인스턴스의 내부 값을 수정할 수 없는 클래스이다.
불변 인스턴스에 저장된 정보는 객체가 소멸하는 순간까지 불변한다. 불변 클래스를 만드는 규칙은 다음과 같다.
- 객체의 상태를 변경하는 setter 등의 변경자 메서드를 제공하지 않는다.
- 클래스를 확장할 수 없도록 한다.
- 클래스를 final로 선언함으로써 하위 클래스에서 객체의 상태를 변경하는 것을 막는다.
- 모든 필드를 final로 선언한다.
- 설계자의 의도를 명확하게 드러낸다.
- 인스턴스를 동기화 없이 다른 스레드에게 건네도 문제가 없어진다.
- 모든 필드를 private으로 선언한다.
- 필드가 참조하는 가변 객체를 클라이언트가 변경하지 못하도록 제한한다.
- public final만 선언해도 불변 객체가 되지만 클라이언트가 해당 값을 직접 사용하고 의존할 수 있다.
- 다음 릴리즈 때 내부 표현을 자유롭게 바꾸기 어려워진다.
- 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.
- 클래스 내부에서 가변 객체를 참조하는 필드는 클라이언트에서 해당 참조를 얻을 수 없도록 해야 한다.
- 해당 필드는 클라이언트가 제공한 객체 참조를 가리키게 해서는 안 된다.
- 접근자 메서드가 해당 필드를 그대로 반환해서도 안 된며, 방어적 복사를 수행해야 한다.
- 클래스 내부에서 가변 객체를 참조하는 필드는 클라이언트에서 해당 참조를 얻을 수 없도록 해야 한다.
2. 함수형 프로그래밍의 장점
Result.java
public Result plus(Result result) {
return new Result(this.score + result.score);
}
피연산자에게 함수를 적용해서 그 결과를 반환하지만, 피연산자 자체는 그대로인 프로그래밍 패턴을 함수형 프로그래밍이라고 한다. 반대로 절차적(혹은 명령형) 프로그램은 메서드에서 피연산자인 자신을 수정해 자신의 상태가 변하게 된다.
이러한 방식은 코드에서 불변이 되는 영역의 비율이 높아진다.
상태 전이를 일으키는 가변 객체에 비해, 불변 객체는 사용이 단순하고 근본적으로 스레드에 안전하여 따로 동기화할 필요가 없다. 불변 객체는 스레드간 안심하고 공유가 가능하다.
- 불변 객체는 재활용성이 높다.
- 불변 클래스는 자주 사용되는 인스턴스를 캐싱해두고 정적 팩토리 메서드 등을 통해 제공할 수 있다.
- 방어적 복사도 필요 없으나, 복사 관련 기능 제공을 지양해야 한다.
- 불변 객체끼리는 내부 데이터를 공유할 수 있다.
- 불변 객체는 그 자체로 실패 원자성을 제공한다.
- 불일치 상태에 빠질 가능성이 없다.
- 객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 장점이 많다.
- 구조가 복잡하더라도 불변식을 유지하기 수월하다.
3. 불변 클래스의 단점
불변 클래스는 값이 다르면 반드시 독립된 객체를 만들어야 한다. 따라서 값의 가짓수가 많은 연산 과정에서는 그만큼 객체를 많이 생성하다 보니 가변 클래스에 비해 비용이 많아진다.
- 많은 라이브러리들은 흔히 쓰일 다단계 연산들을 예측하는 기능을 사용하여 연산 과정 중 불필요한 객체 생성을 줄인다.
- 이러한 기능을 제공하는 가변 동반 클래스를 대게 package-private으로 두고 사용하고 있다.
- 클라이언트들이 원하는 복잡한 연산들을 정확하게 예측할 수 없다면 가변 동반 클래스를 public으로 제공한다.
- String의 가변 동반 클래스인 StringBuilder와 StringBuffer는 public으로 공개되어 있다.
4. 클래스의 불변 보장
클래스가 불변임을 보장하려면 자신을 상속하지 못하게 만들어야 한다.
- 클래스를 final로 선언한다.
- 모든 생성자를 private이나 package-private으로 두고 public 정적 팩토리 메서드를 제공한다.
어떤 불변 클래스는 계산 비용이 큰 값을 나중에 (처음 쓰일 때) 계산하여 final이 아닌 필드에 캐시하기도 한다.
이러한 지연 초기화는 해당 객체가 불변이기 때문에 사용 가능하다. 몇 번을 계산해도 항상 같은 결과가 만들어짐이 보장되기 때문이다.
불변으로 만들 수 없는 클래스라도 변경 가능한 부분을 최소화하자. 객체가 가질 수 있는 상태가 줄어든다면 오류 가능성 또한 줄어든다.
'Prodo 독서 리뷰' 카테고리의 다른 글
[Effective Java] Item 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 (0) | 2021.04.12 |
---|---|
[Effective Java] Item 18. 상속보다는 컴포지션을 사용하라 (0) | 2021.04.11 |
[Effective Java] Item 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라 (0) | 2021.04.11 |
[Effective Java] Item 15. 클래스와 멤버의 접근 권한을 최소화하라 (0) | 2021.04.11 |
[Effective Java] Item 14. Comparable을 구현할지 고려하라 (0) | 2021.04.11 |