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

정적 유틸리티 클래스

잘못 사용한 예제 - 유연하지 않고 테스트하기 어렵다.

 

싱글턴을 잘못 사용한 예제 - 유연하지 않고 테스트 하기 어렵다.

public class SpellChecker {
    private static final Dictionary dictionary = new DefaultDictionary(); // 자원을 직접 명시

    private SpellChecker() {}

    public static boolean isValid(String word) {
        // TODO 여기 SpellChecker 코드
        return dictionary.contains(word);
    }

    public static List<String> suggestions(String typo) {
        // TODO 여기 SpellChecker 코드
        return dictionary.closeWordsTo(typo);
    }
}

 

테스트에 적합하지 않다.

class SpellCheckerTest {

    @Test
    void isValid() {
        // SpellChecker의 dictionary 를 매번 생성한다.
        assertTrue(SpellChecker.isValid("test"));
    }

}

 

 

 

코드의 유연성

위 예제의 SpellChecker 가 여러 사전(어휘용 사전, 테스트용 사전 등)을 사용할 수 있도록 만들어보자. 

간단하게 생각하면 dictionary 필드에서 final 한정자를 제거하고 다른 사전으로 교체하는 메서드를 추가할 수 있다. 하지만 이 방법은 오류를 내기 쉬우며 멀티스레드 환경에서는 쓸 수 없다.

 

사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다. 따라서 클래스가 여러 자원 인스턴스를 지원해야한다. 클라이언트가 원하는 자원을 사용해야한다.

 

싱글톤 방식도 유연하지 않다.

public class SpellChecker {

    private final Dictionary dictionary = new DefaultDictionary();

    private SpellChecker() {}

    public static final SpellChecker INSTANCE = new SpellChecker();

    public boolean isValid(String word) {
        // TODO 여기 SpellChecker 코드
        return dictionary.contains(word);
    }

    public List<String> suggestions(String typo) {
        // TODO 여기 SpellChecker 코드
        return dictionary.closeWordsTo(typo);
    }
}

 

 

의존 객체 주입

인스턴스를 생성할때 생성자에 필요한 자원을 넘겨주는 방식이다.

유연성과 테스트 용이성을 높여준다.

 

Dictionary.java

public interface Dictionary {

    boolean contains(String word);

    List<String> closeWordsTo(String typo);
}

 

DefaultDictionary.java

public class DefaultDictionary implements Dictionary {

    @Override
    public boolean contains(String word) {
        return false;
    }

    @Override
    public List<String> closeWordsTo(String typo) {
        return null;
    }
}

 

MockDictionary.java

public class MockDictionary implements Dictionary{
    @Override
    public boolean contains(String word) {
        return false;
    }

    @Override
    public List<String> closeWordsTo(String typo) {
        return null;
    }
}

 

SpellChecker.java

public class SpellChecker {

    /**
     * Dictionary 가 인터페이스여야한다.
     */
    private final Dictionary dictionary;

    public SpellChecker(Dictionary dictionary) {
        this.dictionary = dictionary;
    }

    /**
     * Supplier 인터페이스를 사용할 수 있다.
     * 만약 Supplier<DefaultDictionary>로 되어있다면, 타입한정자 Supplier<? extends Dictionary> 로 해서 Dictionary 하위 타입을 받자
     * @param dictionarySupplier
     */
    public SpellChecker(Supplier<? extends Dictionary> dictionarySupplier) {
        // 아무것도 받는건 없고 리턴만 한다.
        this.dictionary = dictionarySupplier.get();
    }

    public boolean isValid(String word) {
        // TODO 여기 SpellChecker 코드
        return dictionary.contains(word);
    }

    public List<String> suggestions(String typo) {
        // TODO 여기 SpellChecker 코드
        return dictionary.closeWordsTo(typo);
    }
}

 

disctionary 라는 단 하나의 자원을 사용한다.

자원이 몇개든 의존 관계가 어떻든 상관없이 잘 작동한다. 또한 불변을 보장하여 여러 클라이언트가 의존 객체들을 안심하고 공유할 수 있기도 하다.

 

 

팩터리 메서드 패턴

디자인패턴 포스팅 바로가기

https://devfunny.tistory.com/897

팩토리 메서드 패턴 (Factory Method Pattern)

 

생성자에 자원 팩터리를 넘겨주는 방식이 있다. 팩터리란, 호출할 때마다 특정 타입의 인스턴스를 반복해서 만들어주는 객체를 말한다.

 

DictionaryFactory.java

public interface DictionaryFactory {

    Dictionary getDictionary();

}

 

DefaultDictionaryFactory.java

public class DefaultDictionaryFactory implements DictionaryFactory {
    @Override
    public Dictionary getDictionary() {
        return new DefaultDictionary();
    }
}

 

MockDictionaryFactory.java

public class MockDictionaryFactory implements DictionaryFactory {
    @Override
    public Dictionary getDictionary() {
        return new MockDictionary();
    }
}

 

SpellChecker.java

public class SpellChecker {

    private Dictionary dictionary;


    // Factory 를 통해서 Dictionary 객체를 얻는다.
    public SpellChecker(DictionaryFactory dictionaryFactory) {
        this.dictionary = dictionaryFactory.getDictionary();
    }

    public boolean isValid(String word) {
        // TODO 여기 SpellChecker 코드
        return dictionary.contains(word);
    }

    public List<String> suggestions(String typo) {
        // TODO 여기 SpellChecker 코드
        return dictionary.closeWordsTo(typo);
    }

}

1) Factory를 통해서 Dictionary 객체를 얻는다.

public SpellChecker(DictionaryFactory dictionaryFactory) {
    this.dictionary = dictionaryFactory.getDictionary();
}

 

 

Supplier<T> 인터페이스

위 인터페이스가 팩터리를 표현한 완벽한 예다. Supplier<T>를 입력으로 받는 메서드는 일반적으로 한정적 와일드 카드 타입(bounded wildcard type)을 사용해 팩터리의 타입 매개변수를 제한해야한다. 

 

SpellChecker.java

public class SpellChecker {

    /**
     * Dictionary 가 인터페이스여야한다.
     */
    private final Dictionary dictionary;

    public SpellChecker(Dictionary dictionary) {
        this.dictionary = dictionary;
    }

    /**
     * Supplier 인터페이스를 사용할 수 있다.
     * 만약 Supplier<DefaultDictionary>로 되어있다면, 타입한정자 Supplier<? extends Dictionary> 로 해서 Dictionary 하위 타입을 받자
     * @param dictionarySupplier
     */
    public SpellChecker(Supplier<? extends Dictionary> dictionarySupplier) {
        // 아무것도 받는건 없고 리턴만 한다.
        this.dictionary = dictionarySupplier.get();
    }

    public boolean isValid(String word) {
        // TODO 여기 SpellChecker 코드
        return dictionary.contains(word);
    }

    public List<String> suggestions(String typo) {
        // TODO 여기 SpellChecker 코드
        return dictionary.closeWordsTo(typo);
    }
}

1) Supplier 사용 코드

public SpellChecker(Supplier<? extends Dictionary> dictionarySupplier) {
    // 아무것도 받는건 없고 리턴만 한다.
    this.dictionary = dictionarySupplier.get();
}

 

클라이언트는 자신이 명시한 타입의 하위 타입이라면 무엇이든 생성할 수 있는 팩터리를 넘길 수 있다.

 

클라이언트가 제공한 팩터리가 생성한 타일(Tile)들로 구성된 모자이크(Mosaic)를 만드는 메서드

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