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

사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않음 이 조건을 만족하는 간단한 패턴은 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식

대부분의 클래스는 여러 리소스에 의존
이 책에선는 SpellChecker와 Dictionary를 예로 들고 있음
- 즉, SpellChecker가 Dictionary를 사용하고, 이를 의존하는 리소스 또는 의존성이라고 부름
- 이 때 SpellChecker를 다음과 같이 구현하는 경우가 있음
  - static 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기 어려움
```
public class SpellChecker {
	private static final Lexicon dictionary = ...; // 의존하는 리소스 (의존성)
	private SpellChecker() {} // 객체 생성 방지 

	public static boolean isValid(String word) { ... } 
	public static List<String> suggestions(String typo) { ... } 
}
```
    - 인스턴스를 만들 필요가 없기 때문에 private한 생성자를 만들어주고, public static 메소드들이 있음
    - dictionary가 static한 이유는 static method들이 사용을 해야해서…
  - 싱글턴을 잘못 사용한 예 - 유연하지 않고 테스트하기 어려움
```
public class SpellChecker {
    private static final SpellChecker INSTANCE = new SpellChecker(new KoreanDictionary());

    private final Lexicon dictionary;

    private SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }

    public static SpellChecker getInstance() {
        return INSTANCE;
    }

    public boolean isValid(String word) { return true; }
    public List<String> suggestions(String typo) { return null; }
}
```
  - 두 방식 모두 dictionary 를 단 하나만 사용한다고 가정할때 별로…
  - 직접 명시 후 고정되어 있는 변수는 테스트를 하기 힘들게함
  - 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글톤 방식이 적합하지 않음
    - 따라서 의존성을 바깥으로 분리하여 외부로부터 주입받도록 해야함 (DI)

의존 객체 주입 (DI)

의존 객체 주입은 유연성과 테스트 용이성을 높여줌!
```
public class SpellChecker { 
	private final Lexicon dictionary; 

	private SpellChecker(Lexicon dictionary) { 
    		this.dictionary = Objects.requireNonNull(dictionary); 
 	} 

	public boolean isValid(String word) { return true; } 
	public List<String> suggestions(String typo) { return null; } 

	public static void main(String[] args) {
		Lexicon lexicon = new KoreanDictionary();
		SpellChecker spellChecker = new SpellChecker(lexicon);
		spellChecker.isValid("hello");
	}
}

interface Lexicon{}

class KoreanDictionary implements Lexicon {}
class TestDictionary implements Lexicon {} // test가 가능해짐
```
- 불변을 보장하여 (변경될 일이 없음) 여러 클라이언트가 의존 객체들을 안심하고 공유할 수 있음
- 위의 예시에서는 단순히 한개의 자원만 사용하지만, 자원이 몇 개든 의존 관계가 어떻게 되든 잘 작동함!
  - 불변을 보장하여 여러 클라이언트가 의존 객체를 안심하고 사용할 수 있음
  - 의존 객체 주입은 생성자, 정적 팩터리, Builder 모두에 똑같이 적용 가능
- Factory란?
  - 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체
  - 팩토리 메서드 패턴은 의존 객체 주입 패턴을 응용해서 구현한 것
  - Supplier<T> 인터페이스는 팩터리를 표현한 완벽한 예시
```
@FunctionalInterface
public interface Supplier<T> {

    /**
     * Gets a result.
     *
     * @return a result
     */
    T get();
}

Mosaic create(Supplier<? extends Tile> tileFactory) { ... }
```
  - 이 방식을 사용해 클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든 생성할 수 있는 팩터리를 만들 수 있음

Conclusion

의존 객체 주입이 유연성과 테스트 용이성을 개선해주지만, 의존성이 너무 많은 프로젝트에서는 코드를 어지럽게 하며, 스프링 같은 의존 객체 주입 프레임워크를 사용해 코드의 어지러움을 해소할 수 있음!