많은 클래스가 하나 이상의 자원에 의존한다.
맞춤법 검사기는 사전에 의존하는데, 이런 클래스를 정적 유틸리티 클래스로 구현하는 모습을 많이 볼 수 있다.
//정적 유틸리티를 잘못 사용한 예
public class SpellChecker {
private final Lexicon dictionary = ...;
private SpellChecker() {} // 객체 생성 방지
public static boolean isValid(String word) {...}
public static List<String> suggestions(String typo) {...}
}
//싱글턴을 잘못 사용한 예
public class SpeelChecker {
private final Lexicon dictionary = ...;
private SpellChecker(...){}
public static SpeelChecker INSTANCE = new SpeelChecker(...);
public boolean isValid(String word) {...}
public List<String> suggestions(String typo) {...}
}
두 방식 모두 유연하지 않고 테스트하기 어렵다는 단점이 있다. 또한 사전을 단 하나만 사용한다고 가정했을 때 효율적이지 못하다.
실제 사용 시에는 언어별, 특수 어휘용, 테스트용 사전이 필요할 수 있다. final 한정자를 제거하고 다른 사전으로 교체하는 메서드를 추가할 수 있으나 오류를 내기 쉬우며, 멀티스레드 환경에서는 쓸 수 없다.
인스턴스 생성시 생성자에 필요한 자원을 넘기자
위 방식 대신 클래스(SpellChecker)가 여러 자원 인스턴스를 지원해야 하며, 클라이언트가 원하는 자원(dictionary)을 사용해야 한다. 즉, 클래스를 생성할 때 의존 객체인 사전을 주입하면 된다.
//의존 객체 주입은 유연성과 테스트 용이성을 높여준다.
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) {...}
}
자원이 몇 개든 의존 관계가 어떻든 상관없이 잘 작동한다. 또한 생성자, 정적 팩터리, 빌더 패턴 모두 똑같이 응용할 수 있다.
이 패턴의 변형으로, 생성자에 자원 팩터리를 넘겨주는 방식이 있다. 팩터리란 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체를 말한다. 즉 팩터리 메서드 패턴을 구현한 것이다.
자바 8에서 등장한 Supplier<T> 인터페이스가 팩터리를 표현한 완벽한 예다.
//Lexicon
class Lexicon{
public void print(){
System.out.println("Lexicon");
}
}
//국어사전
class KoreanDictionary extends Lexicon{
@Override
public void print(){
System.out.println("Korean");
}
}
//영어사전
class EnglishDictionary extends Lexicon{
@Override
public void print(){
System.out.println("English");
}
}
//인스턴스를 생성하는 팩터리 클래스
class LexiconFactory {
protected Lexicon createProduct(String name){
if("Kor".equals(name)){
return new KoreanDictionary();
}else {
return new EnglishDictionary();
}
}
}
//SpeelChecker 사용 예
public class SpellChecker {
private final Lexicon dictionary;
//의존 객체 주입
public SpellChecker(Supplier<? extends Lexicon> lexicon) {
this.dictionary = lexicon.get();
this.dictionary.print();
}
public static void main(String[] args) {
LexiconFactory lexiconFactory = new LexiconFactory();
Supplier<Lexicon> lexiconSupplier = () -> lexiconFactory.createProduct("Kor");
SpellChecker spellChecker = new SpellChecker(lexiconSupplier);
}
}
Supplier<T>를 입력으로 받는 메서드는 일반적으로 한정적 와일드카드 타입을 사용해 팩터리의 타입 매개변수를 제한해야 한다. 이 방식을 사용해 자신이 명시한 타입(여기서는 Lexicon)의 하위 타입이라면 무엇이든 생성할 수 있는 팩터리를 넘길 수 있다.
정리
클래스가 내부적으로 하나 이상의 자원에 의존할 때는 필요한 자원 또는 그 자원을 만들어주는 팩터리를 생성자에 넘겨주자. 의존 객체 주입이라 하는 이 방법은 클래스의 유연성, 재사용성, 테스트 용이성을 개선해준다.
'Study > Effective Java' 카테고리의 다른 글
[아이템07] 다 쓴 객체 참조를 해제하라 (0) | 2022.09.30 |
---|---|
[아이템04] 인스턴스화를 막으려거든 private 생성자를 사용하라 (0) | 2022.09.13 |
[아이템03] private 생성자나 열거 타입으로 싱글턴임을 보증하라 (0) | 2022.09.08 |
[아이템02] 생성자에 매개변수가 많다면 빌더를 고려하라 (0) | 2022.08.22 |
[아이템01] 생성자 대신 정적 팩터리 메서드를 고려하라 (0) | 2022.08.19 |