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

대부분의 클래스가 하나 이상의 자원에 의존한다. SpellChecker를 다음과 같이 구현하는 모습이 드물지 않게 보인다.

static 유틸리티 클래스(아이템4)

// 부적절한 static 유틸리티 사용 예 - 유연하지 않고 테스트 할 수 없다.
public class SpellChecker {

    private static final Lexicon dictionary = new KoreanDicationry();

    private SpellChecker() {
        // Noninstantiable
    }

    public static boolean isValid(String word) {
        throw new UnsupportedOperationException();
    }


    public static List<String> suggestions(String typo) {
        throw new UnsupportedOperationException();
    }
}

interface Lexicon {}

싱글톤으로 구현(아이템3)

// 부적절한 싱글톤 사용 예 - 유연하지 않고 테스트 할 수 없다.
public class SpellChecker {

    private final Lexicon dictionary = new KoreanDicationry();

    private SpellChecker() {
    }

    public static final SpellChecker INSTANCE = new SpellChecker() {
    };

    public boolean isValid(String word) {
        throw new UnsupportedOperationException();
    }


    public List<String> suggestions(String typo) {
        throw new UnsupportedOperationException();
    }

}

두 방식 모두 사전을 단 하나만 사용할 때 훌륭해보이지 한다. 실제로 각 언어의 맞춤법 검사기는 사용하는 사전이 다르고 테스트용 사전도 사용할 수 도 있다.

어떤 클래스가 사용하는 자원에 따라 행동을 달리 해야 하는 경우에는 스태틱 유틸리티 클래스와 싱글톤을 사용하는 것은 부적절하다.

그런 요구사항을 만족할 수 있는 것이 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식, 이는 의존 객체 주입의 한 형태이다.

//의존 객체 주입은 유연성과 테스트 용이성을 높인다.
public class SpellChecker {

    private final Lexicon dictionary;

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

    public boolean isValid(String word) {
        throw new UnsupportedOperationException();
    }
    
    public List<String> suggestions(String typo) {
        throw new UnsupportedOperationException();
    }

}

의존 객체 주입은 생성자, 정적 팩터리, 빌더 모두에 응용 가능하다.
이 패턴의 변형으로 생성자에 자원 팩터리를 넘겨주는 방식이 있다. 이 방법은 자바8에서 소개한 Supplier<T> 인터페이스가 그런 팩터리로 쓰기에 완벽하다. 입력으로 받는 메서드는 일반적으로 한정적 와일드카드타입을 사용해 팩터리의 타입 매개변수를 제한해야 한다.

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

의존성 객체 주입이 유연성과 테스트 용이성을 개선해주지만 의존성이 수 천개나 되는 큰 프로젝트에서는 코드를 어지럽게 만들기도 한다. 그럴때는 대거, 스프링 등 의존 객체 주입 프레임워크를 사용하면 해소할 수 있다.

정리

클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다.