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

의존 자원이 있을 때의 잘못된 사용(정적 유틸리티 클래스, 싱글톤 클래스)

• 많은 클래스가 하나 이상의 자원에 의존하는데, 예를 들어 맞춤법 검사기는 사전에 의존을 하게 되는데 이를 정적 유틸리티 클래스나 싱글톤으로 구현하는 것은 좋지 않다

• 아래와 같은 방식으로는 사전의 종류를 다양화 할 수 없음 → 만약 여러 사전을 사용하도록 final을 제거하고 다른 사전으로 교체하는 메서드를 도입한다면 ?? ⇒ 어색하고 오류 내기 쉬움. 멀티스레드 환경에서 사용 불가

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

// 정적 유틸리티 클래스
public class SpellChecker{
		private static final Lexicon dictionary = ...;

		private SpellChecker() {} // 객체 생성 방지

		public static boolean isValid(String word) { ... }
		public static List<String> suggestions(String typo) { ... }
}

// 싱글턴
public class SpellChecker{
		private final Lexicon dictionary = ...;
	
		private SpellChecker(...) {}
		public static SpellChecker INSTANCE = new SpellChecker( ...);

		public boolean isValid(String word) { ... }
		public List<String> suggestions(String typo) { ...}
}

의존 객체 주입을 이용하기

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

• 불변을 보장하여 같은 자원을 사용하려는 여러 클라이언트가 의존 객체들을 안심하고 공유할 수 있음

• 이 패턴의 쓸만한 변형으로 생성자에 자원 팩터리를 넘겨주는 방식이 있음

변형 : 생성자에 자원 팩터리를 넘겨주는 방식

• 자바 8에서 소개한 Supplier<T> 인터페이스가 팩터리를 표현한 완벽한 예임

• Supplier<T>를 입력으로 받는 메서드는 일반적으로 한정적 와일드카드 타입(bounded wildcard type)을 사용해 팩터리의 타입 매개변수를 제한해야 함. 이 방식을 사용하면 클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든 생성할 수 있는 팩터리를 넘길 수 있음

• Mosaic create(Supplier<? extends Tile> tileFactory) { ... }

단점

• 의존 객체 주입이 유연성, 테스트 용이성을 개선해 주기는 하지만 의존성이 수 천개나 되면 코드를 어지럽게 만들기도 함. → Dagger, Guice, Spring같은 의존 객체 주입 프레임워크 사용하면 해소 가능