[이펙티브 자바] Item5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라.

 

item05. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라. 

클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스의 동작에 영향을 준다면 정적 유틸리티 클래스나 싱글톤 방식이 적합하지 않다. 

 

많은 클래스가 하나 이상의 자원에 의존하는데 책에서 예제로는 맞춤법 검사기를 예로 들고 있다. 

맞춤법 검사기는 Dictionary에 의존한다고 가정한다. 

 

1) 정적 유틸리티 클래스

public class SpellChecker
{
   // 자원을 직접 명시한 코드 (자원을 직접 생성한다, new 로 생성 )
   private static final Dictionary dictionary = new Dictionary();
   
   private SpellChecker()
   {
   
   }
   
   public static boolean isValid(String word)
   {
      return dictionary.contains(word);
   }
   
   public static List<String> suggestions(String typo)
   {
      return dictionary.closeWordsTo(typo);
   }
}

-> 정적 유틸리티 클래스는 자원을 직접 생성해서 사용하고 있는데 이렇게 사용하면 유연성과 재사용성이 떨어지고, 테스트하기 어렵다. 

지금은 Dictionary클래스가 간단하지만 예를 들어 이 클래스를 사용하는게 자원 소모가 많다고 가정하자. 

그러면 테스트를 할 때 지금은 SpellChecker의 기능에 대해서만 테스트 하고 싶지만 이 기능을 테스트 하기 위해서는 Dictionary 클래스를 생성해서 사용해야 한다. 이렇게 되면 테스트 하는데 어려워진다. 

 

그리고 재사용성에 대해서 생각하면 지금은 Dictionary인데 만약 한글 맞춤법에 대해서 검사하고 싶다~ 하면 어떻게 해야하는가..? 

한글 말고 영어로 할 때는? 그럴 때 마다 계속 새로운 SpellChekcer를 만드는건 굉장히 비효율적이다. 

 

 

2) 싱글톤 방식

정적 유틸리티 방법 말고는 싱글톤 방식이 있다. 

public class SpellChecker
{
   private final Dictionary dictionary = new Dictionary();
   
   private SpellChecker()
   {
   
   }
   
   public static final SpellChecker INSTANCE = new SpellChecker();
   
   public boolean isValid(String word)
   {
      return dictionary.contains(word);
   }
   
   public List<String> suggestions(String typo)
   {
      return dictionary.closeWordsTo(typo);
   }
}

-> 이 방식 역시 자원을 직접 명시해주고 있기 때문에 재사용성, 유연성이 떨어지고, 테스트하기 어렵다. 

 

 

📢 1) 과 2) 방식 모두 사전을 하나만 사용할 수 밖에 없기 때문에 좋은 방법이 아니다. 

실제로는 사전은 언어별로 존재하고 있고 특수 어휘용 사전이나 테스트 사전이 필요한 경우도 있는데 사전 하나로 이 모든것을 대응하기는 어렵다. 

 

즉, 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다. 

 

 

3) 의존 객체 주입 

1)과 2) 방법 대신에 SpellChecker가 여러 자원 인스턴스를 지원해야 하고, 클라이언트가 원하는 자원(Dictionary)을 사용해야 한다. 

이 방법이 바로 의존 객체 주입으로 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식이다. 

public class SpellChecker
{
   private final Dictionary dictionary;
   
   // 인스턴스를 생성할 때 필요한 자원을 넘겨주는 방식
   public SpellChecker(Dictionary dictionary )
   {
      this.dictionary = dictionary;
   }
   
   public boolean isValid(String word)
   {
      return dictionary.contains(word);
   }
   
   public List<String> suggestions(String typo)
   {
      return dictionary.closeWordsTo(typo);
   }
}

-> 이렇게 사용하면 Dictionary 라는 딱 하나의 객체를 사용하지만 자원이 몇개든 의존 관계가 어떻든 상관없이 잘 동작한다. 

 

 

 

🙌 팩터리 메서드 패턴 

위의 방법에 변형으로는 생성자에 자원 팩토리를 넘겨주는 방식이 있다. 

팩터리란 호출할 때 마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체를 말한다. 

public class SpellChecker
{
   private final Dictionary dictionary;
   
   public SpellChecker(DictionaryFactory dictionaryFactory)
   {
      this.dictionary = dictionaryFactory.get();
   }
   
   public boolean isValid(String word)
   {
      return dictionary.contains(word);
   }
   
   public List<String> suggestions(String typo)
   {
      return dictionary.closeWordsTo(typo);
   }
}

public class DictionaryFactory
{
   public  Dictionary get()
   {
      return new DefaultDictionary();
   }

}

이렇게 팩터리를 사용해서 호출할 때 마다 특정 인스턴스를 반복해서 만들어줄 수도 있는데, 

이때 함수형 인터페이스인 Supplier가 팩터리를 표현한 완벽한 예라고 할 수 있다. 

[이펙티브 자바] Item03 완벽공략. 함수형 인터페이스 (tistory.com)

[이펙티브 자바] Item03 완벽공략. 함수형 인터페이스

Supplier<T>는 인자를 받지 않고 return값만 존재하는 함수이다. (공급자 역할) 

 

public class SpellChecker
{
   private final Dictionary dictionary;
   
   // 인스턴스를 생성할 때 필요한 자원을 넘겨주는 방식
   public SpellChecker(Supplier<Dictionary> factorySupplier) // Supplier<T>가 팩터리를 표현한 완벽한 예
   {
      this.dictionary = factorySupplier.get();
   }
   
   
   public boolean isValid(String word)
   {
      return dictionary.contains(word);
   }
   
   public List<String> suggestions(String typo)
   {
      return dictionary.closeWordsTo(typo);
   }
}

Supplier<T>를 입력으로 받는 메서드는 일반적으로 한정적 와일드 카드 타입을 사용해 팩터리의 타입 매개변수를 제한해야 한다. 

 

public class SpellChecker
{
   private final Dictionary dictionary;
   
   // 인스턴스를 생성할 때 필요한 자원을 넘겨주는 방식
   public SpellChecker(Supplier<? extends Dictionary> factorySupplier) // Supplier<T>가 팩터리를 표현한 완벽한 예
   {
      this.dictionary = factorySupplier.get();
   }
   
   
   public boolean isValid(String word)
   {
      return dictionary.contains(word);
   }
   
   public List<String> suggestions(String typo)
   {
      return dictionary.closeWordsTo(typo);
   }
}

-> < ? extends Dictionary> 를 통해서 클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든 생성할 수 있는 팩터리를 넘길 수있다. 

 

 

👩‍💻

사용하는 자원에 따라 동작이 달라지는 클래스는 정적 유틸리티 클래스나 싱글톤 방식을 사용하는 것은 좋지 않은 방법이다. 

이 대신 필요한 자원을 (혹은 이 자원을 생성해주는 팩터리를) 생성자에 넘겨주는 의존 객체 주입을 사용하는 것을 권장한다. 

의존 객체 주입을 사용하면 클래스의 유연성, 재사용성, 테스트 용이성을 개선할 수 있다. 

 

근데 의존성이 만약 수천개가 되는 큰 프로젝트다 하면 이 의존 객체 주입이 코드를 지저분하게 만들기도 한다. 

(의존성이 수천개만 의존 주입 코드만 수천줄 될듯..)

-> 이에 대해서는 대거 Dagger, 주스 Guice, 스프링 Spring 과 같은 의존 객체 주입 프레임워크를 사용하면 해소할 수 있다.