아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라. - ksw6169/effective-java GitHub Wiki
- 맞춤법 검사기가 사전에 의존하여 기능을 수행하도록 코드를 작성해보자. (아래는 각각 정적 유틸리티, 싱글톤을 이용하는 예제다.)
// 정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기가 어렵다.
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 = ...;
public static SpellChecker INSTANCE = new SpellChecker(...);
private SpellChecker(...) {}
public boolean isValid(String word) { ... }
public List<String> suggestions(String typo) { ... }
}
- 두 방식 모두 사전을 단 하나만 사용한다고 가정한다는 점에서 좋지 않은 방식이다.
- 실제로는 여러 사전이 사용될 수 있고, 상황에 따라 사전이 달라질 수도 있다.
- 이를 해결하기 위해 final 한정자를 제거하고 dictionary에 Lexicon 구현체를 직접 할당할 수도 있으나 클라이언트가 원하는 dictionary를 매번 할당해줄 수 없으므로 이 방식도 좋은 방식이 아니다.
- 결국 사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.
- 클래스(SpellChecker)가 여러 자원 인스턴스를 지원해야 하며, 클라이언트가 원하는 자원(dictionary)을 사용해야 한다는 문제의 조건을 만족하기 위해 의존 객체 주입 방식을 사용할 수 있다. 이 방식은 클래스의 유연성, 재사용성, 테스트 용이성을 크게 개선해준다.
(1) 생성자에 의존 객체를 주입해주는 방식
- 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 의존 객체 주입 방식이다.
public class SpellChecker {
private final Lexicon dictionary;
public SpellChecker(Lexicon dictionary) {
this.dictionary = Objects.requireNonNull(dictionary);
}
public boolean isValid(String word) { ... }
public List<String> suggestions(String typo) { ... }
}
(2) 생성자에 의존 객체를 생성하는 팩토리를 넘겨주는 방식
- 생성자에 의존 객체를 넘겨주는 방식의 변형으로 생성자에 자원 팩토리를 넘겨주는 방식을 사용할 수도 있다.
- 여기서 팩토리란 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체를 말한다.
- 대표적으로 Java 8의
Suppiler<T>
인터페이스가 팩토리를 표현한 완벽한 예다. -
Supplier<T>
를 입력으로 받는 메소드는 일반적으로 한정적 와일드카드 타입(bounded wildcard type)을 사용해 팩토리의 타입 매개변수를 제한해야 한다. - 이 방식을 사용하면 클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든 생성할 수 있는 팩토리를 넘길 수 있다.
- 대표적으로 Java 8의
// 클라이언트가 제공한 팩토리가 생성한 타일(Tile)들로 구성된 모자이크(Mosaic)를 만드는 메소드
Mosaic create(Supplier<? extends Tile> tileFactory) { ... }
- Effective Java 3/E