[이펙티브 자바] Item17. 변경 가능성을 최소화 하라. (불변 클래스를 만들 때 고려할 것)

 

[이펙티브 자바] Item17. 변경 가능성을 최소화하라. 

[이펙티브 자바] Item17. 변경 가능성을 최소화 하라. (불변 클래스의 장점과 단점) (tistory.com)

[이펙티브 자바] Item17. 변경 가능성을 최소화 하라. (불변 클래스의 장점과 단점)

저번 글에서 불변 클래스의 개념과  만드는 다섯가지 규칙, 그리고 불변 클래스의 장점과 단점에 대해서 배웠다. 

불변 클래스를 만들 때 다섯가지 규칙에 더해서 오늘은  불변 클래스를 만들 때 고려해야 할 점에 대해서 학습했다. 

 

 

불변 클래스를 만드는 다섯가지 규칙에서 

클래스를 확장할 수 없도록 해야한다고 했고, 상속을 하지 못하게 하는 가장 쉬운 방법으로 final 클래스로 선언하는 방법에 대해 소개했다. 

그런데 final 클래스로 선언해 상속을 막는 방법 외에도 더 유연한 방법들이 있다. 

-> 모든 생성자를 private 또는 package-private 로 만들고 public 정적 팩터리로 제공하는 방법이다. 

 

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);
   
   private Complex(double re, double im) // private 또는 package-private 생성자를 사용해서도 상속을 막을 수 있다.
   {
      this.re = re;
      this.im = im;
   }
   
   /** private 생성자를 사용하면 인스턴스를 만들 수 없는데.. 그렇다면 이 클래스는 어떻게 사용하는가?
    * -> 정적팩터리를 사용
    */
   public static Complex valueOf(double re, double im)
   {
      return new Complex(re, im);
   }
  }

이렇게 생성자를 private로 만들어주고 나면 이 클래스를 사용하기 위해 인스턴스를 만들어야하는데 private로 생성자를 만들었기 때문에 이 클래스를 사용할 수 없다.. 따라서 public 정적 팩터리 메서드를 통해서 해당 클래스를 사용하면 된다. 

public static void main(String[] args)
{
   /** private 생성자를 사용하면 인스턴스를 만들 수 없는데.. 그렇다면 이 클래스는 어떻게 사용하는가?
    * -> 정적팩터리를 사용
    * 장점: final 클래스는 상속을 아예 막아버리지만 private 생성자를 사용하면 생성자를 좁힌 상태에서는 상속이 가능하다.
    */
   Complex complex = Complex.valueOf(1, 0.22);
}

 

private 생성자 + public 정적 팩터리 메서드 방식으로 사용하면 패키지 바깥의 클라이언트에서 바라본 이 불변 객체는 사실상 final 이다. 

왜냐하면 public이나 protected 생성자가 없기 때문에 다른 패키지에서는 이 클래스를 확장하는게 불가능하기 때문이다. 

 

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

private static class MyComplex extends Complex
{
   private MyComplex(double re, double im)
   {
      super(re, im);
   }
}

final로 클래스를 선언해 상속을 막아버리는 것보다 private 또는 package-private 생성자를 사용하면 해당 클래스 내에서는 상속이 가능해 좀 더 유연하게 사용할 수 있다! 

 

 

❗ BigInteger와 BigDecimal 주의사항 

BigInteger와 BigDecimal을 설계할 당시에는 불변 객체가 사실상 final 이어야 한다는 생각이 널리 퍼지지 않았다고 한다. 

그래서 BigInteger와 BigDecimal은 상속해 재정의할 수 있게 설계되었고,... 따라서 지금까지도 하위호완성 때문에 문제가 있다고 한다..! 

public static BigInteger safeInstance(BigInteger val)
{
   return val.getClass() == BigInteger.class ? val : new BigInteger(val.toByteArray());
}

따라서 BigInteger와 BigDecimal을 인스턴스의 인수로 받는다면 주의 해야 한다!! 

이 값이 불변이어야 클래스의 보안을 지킬 수 있다면 인수로 받은 객체가 '진짜'  BigInteger 혹은 BigDecmal인지 반드시 확인해야 한다. 

-> 신뢰할 수 없는 하위 클래스의 인스턴스라고 확인되면 이 인수들은 가변이라고 가정하고 방어적 복사를 사용해야 한다!!

 

 

 

😮 모든 "외부에 공개하는" 필드가 final 이어야 한다. 

불변 클래스를 만드는 다섯가지 규칙에 대해서 학습할 때는 모든 필드가 final이고 어떤 메서드도 그 값을 수정할 수 없어야 한다고 했지만 성능을 위해 살짝 완화할 수 있다. -> "어떤 메서드도 객체의 상태 중 외부에 비치는 값을 변경할 수 없다" 

 

어떤 불변 클래스는 계산 비용이 큰 값을 나중에 계산해서 final이 아닌 필드에 캐시해놓기도 한다.

똑같은 값을 다시 요청하면 캐시해둔 값을 반환하여 계산 비용을 절감하는 것이다! 

 

 

 

📚 정리 

- getter 가 있다고 해서 무조건 setter를 만들지 말자! 

: 클래스는 꼭 필요한 경우가 아니라면 불변이어야 한다. 불변 클래스는 장점이 많고 단점이라고 할 건 특정 상황에서의 잠재적 성능 저하뿐이다.  (값이 다르면 반드시 별도의 객체로 만들어야함) 

 

 

- 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄이자. 

: 모든 클래스를 불변으로 만들 수는 없기 때문에 객체가 가질 수 있는 상태의 수를 줄이면 그 객체를 예측하기 쉬워지고 오류가 생길 가능성이 줄어든다. 그러므로 꼭 변경해야 할 필드를 뺀 나머지는 모두 final로 선언하자!! 

 

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

 

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

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